On Tue, 11 Jun 2002, Terry Lambert wrote:
TL>Harti Brandt wrote:
TL>> In MHO this idea is based on a fundamental misunderstanding of what a
TL>> device is under unix. If you need such a behaviour you should put another
TL>> abstraction on top of you devices (as the filesystem is put on top of
TL>> disks and sockets on top of network devices), that handle multiple
TL>> contexts for multiple processes. A device is just a device...
TL>I really disagree with this. SVR4 and AIX have supported clone
TL>devices for a very long time now, starting with support for pty's.
TL>Cloning eliminates several things:
TL>o The search requirement for allocating an instance of a
TL> device type; this is generally a linear search, through
TL> an O(n^2) interface, e.g. looking up the next pty in the
TL> space defined by /dev/pty*
TL>o The normal limit on the number of devices that's imposed
TL> because of both the namespace limits, and on static
TL> declaration of things that should be allocated on a per
TL> instance bases, up to the limits of system resources
TL>o The system dependence on naming that goes into building
TL> code that it portable between systems.
TL>For pty's, in particular, instance is identified via minor number;
TL>the need to actually try to open and obtain exclusive use of the
TL>master pty, up to the first unallocated one, and the fact that
TL>when you run out of names, you run out of pty's, are both enough,
TL>each on their own, to justify cloning devices.
TL>FreeBSD today can not run more than one VMWare seassion at a time
TL>because it lacks the ability to distinguish open instances to the
TL>device that exports the VMWare kernel context information to the
TL>user space application: because FreeBSD lacks device cloning.
TL>Rather than trying to say what someone should do, it'd be nice,
TL>at least in the case of commercial code that can't be demanded to
TL>be rewritten, and which runs under a non-native ABI on FreeBSD,
TL>to be able to support all of the functionality of the OS whose
TL>ABI is being emulated, and thus, if for no other reason, to
TL>support device cloning.
TL>It's not like third parties are going to be willing to port their
TL>code to FreeBSD, particularly after the last 6 years or so of
TL>being told *by FreeBSD people* to target the Linux ABI.
TL>So trying to change people wanting cloning in the first place is
TL>not really a winable fight.
I was talking about real devices, not pseudo devices that you can get out
of thin air. Device driver for real devices should be just what they are:
device drivers. If you take a disk driver, then there is no code there
that tries to present multiple contexts to multiple openers - supporting
this is the task of the file system. If you take a sound card, the
multiplexing stuff, that handles multiple processes open the soundcard
should not be in the driver, but in the abstraction above. The same holds
for the network devices. The situation is different for pseudo devices
which you can create on demand.
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message