[no subject]

The only *real* difference I can see here is that programs built to
run against the Linux ABI won't behave correctly when run on FreeBSD
under FreeBSD's Linux ABI implementation.

> Yes. And to open a file on disk I open /dev/da0s1a and then issue an ioctl
> to get to the file (and a new device entry) and every disk driver
> implements the file system. Every sound device writer writes all the
> mixing and code conversion code into his driver... Just idiotic...

This is a reductio ad absurdum argument.  It leaves no room for the
idea that there exist inappropriate applications of technology.  Just
because a hammer works once, does not make every problem a nail.

If you looked at the recent followup by the original poster, you will
see that what he has, in fact, is a device driver that really needs
to permit him formatted access to a bus.

A bus is an application for which cloning is a *really* good model to
use for devices.


> Mixing and code conversion is something you should do above the device
> layer, just as you do TCP not in the network driver. What's the the API
> that the user program sees from this generic layer is just a matter of
> taste - cloning pseudo devices would be just fine.

I understand your point, but I think you have chosen a particularly
bad example.

The problem with this example is that there have been a very large
number of times where I have thought it would be useful to be able to
have the TCP connection associated with the active browser window
(the one in the foreground and/or the one that is selected as the
active window -- having the input focus) have a higher priority than
the other TCP connections associated with other windows belonging to
the same browser application.  It would be incredibly useful if I
could start a number of downloads that I know will take a long time,
and then continue browsing, and have the application "just do what I
want", by prioritizing traffic based on which window has my personal
attention.

I know that the typical answer to this is "rewrite the Internet to
support QOS", but this isn't really an answer.  Without a negotiated
QOS, I can still control the number of buffers in use on the peer
which provides my connectivity by diddling with the window size
advertisements my machine sends to the peer router, so that the peer
router buffers don't become saturated with data for the file transfer
sessions, and therefore my interactive response does not suffer (the
current AltQ integration into FreeBSD does *NOT* use this technique,
and so can not make the same guarantees, particularly when there is
an inpedence mismatch between the ISP link and the "last mile" link
to my machine, with my "last mile" being significantly slower).
Julian Elisher built something similar to this into the Whistle
InterJet, near the end, but it was only useful for trafic shaping,
not explicit QOS control by the application.

I guess my point to this whole example is that where you draw the
line dictates the properties of the resulting system, and the more
control you give to the application, the better, in most cases.  In
a perfect world, I think this would include TCP.

-- Terry

To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-current" in the body of the message