In article <200411271904.04736.abuse@spamalicious.com>,
Charles M. Hannum <abuse@spamalicious.com> wrote:
>On Saturday 27 November 2004 18:52, Christos Zoulas wrote:
>> The following patch turns /dev/bpfX into cloners. Only one is really
>> needed, /dev/bpf, but for now we can leave the stray /dev/bpfX's until we
>> fix the source code. Comments?
>
>Thanks (well, not really) to ptyfs, there are already four methods of creating 
>cloning devices in the kernel.  This adds a fifth.
>
>This has already way out of hand.  Before you add more one-off hacks, it is 
>time to sit down and actually DESIGN how cloning devices are going to work 
>globally.

I wondered how many types of cloning devices we had and how cloning was
done, so here are the results.

Cloner type 1: In the device open routine, open a new file descriptor, hijack
	       its fileops, set dupfd to that file descriptor, return ENXIO.
	       Used by: svr4_net.c [net], dmover_io.c, bpf.c, kern_systrace.c

Cloner type 2: In the device open routine, open a new device, set dupfd to
	       point to the file descriptor corresponding to the new device,
	       return ENXIO. Used by: tty_ptm.c, svr4_net.c [pty]

Cloner type 3: In the device open routine, set dupfd to the minor number of
	       the device opened, and return ENODEV. Used to implement /dev/fd
	       in kern_descrip.c.

Cloner type 4: In the device open routine, set dupfd to the appropriate fd
	       taken from the fdesc fs node, and return ENODEV. Used to
	       implement /dev/fd in fdesc_vnops.c

Cloner type 5: In the device open routine, set dupfd to the file descriptor
	       passed in the control message. Return ENXIO if the file
	       descriptor is setup in this open, or ENODEV if it was set
	       in a previous open? Used by: portal_vnops.c

So we have cloners 3, 4, 5 which just pass an already open file descriptor
for the process, cloner 2 which opens a new device, and cloner 1 which
opens a new descriptor and then mutates its fileops to implement
characteristics of a particular device.

Cloners 3, 4, 5 are not very interesting; they are just another form of dup.
Cloner 2 is required and cloner 1 cannot be used to implement it because
we need to have the devices present and accessed through the filesystem
(being able to stat them, chmod them, etc.)

Cloner 1 is the most powerful one and the simplest to implement because
it does not require another pass through the filesystem, but because of
that, it cannot be used to implement things that are present in the
filesystem such as ptys.

I don't see why this is all that bad and why everything needs to be done
the same way. In fact, I don't see a single solution that will satisfy the
requirements of all the cloning devices.

christos