Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jun 2002 00:07:03 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Harti Brandt <brandt@fokus.gmd.de>
Cc:        Maksim Yevmenkin <m_evmenkin@yahoo.com>, current@FreeBSD.ORG
Subject:   Re: Device cloning
Message-ID:  <3D06F317.C2FFB40F@mindspring.com>
References:  <20020612083231.B35453-100000@beagle.fokus.gmd.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Harti Brandt wrote:
> You just don't know what you are talking about. This is exactly the
> difference between the current Linux sound (1 device) and FreeBSD (1
> device/channel). In FreeBSD I can use N channels with different audio
> formats and speeds, in Linux I'm stuck to using all the channels with the
> same format. Try to write a conferencing tool, that has to work in a
> heterogenous environment.

That's not an artifact of it being a "single device"; with a context
per open instance, it's either an artifact of inability to manipulate
the instance data via ioctl(), or the failure of the user software to
open the underlying device more than once, so that it has different
instances to work with to achieve your goal.

From an application point of view, the only difference is whether you
have to guess names to get at the extra channels, or just open the
same name more than once.  In FreeBSD, the device names are only a
proxy for the differences in major/minor number pairs (as are all
devices).  The differences in minor numbers are themselves just a
proxy for instance information.  Where the instance comes from is
really irrelevent, to the application, so long as it gets (1) one
instance per fd, and (2) more than one fd.

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@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D06F317.C2FFB40F>