Date: Tue, 11 Jun 2002 10:43:07 +0200 (CEST) From: Harti Brandt <brandt@fokus.gmd.de> To: Terry Lambert <tlambert2@mindspring.com> Cc: Maksim Yevmenkin <m_evmenkin@yahoo.com>, <current@FreeBSD.ORG> Subject: Re: Device cloning Message-ID: <20020611103826.W35132-100000@beagle.fokus.gmd.de> In-Reply-To: <3D05ACE9.ED09D57E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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> 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> TL>Cloning eliminates several things: TL> 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> 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> TL>o The system dependence on naming that goes into building TL> code that it portable between systems. TL> 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> 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> 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> 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> TL>So trying to change people wanting cloning in the first place is TL>not really a winable fight. Terry, 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 -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de 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?20020611103826.W35132-100000>