Re: Simplifying devfs: minor == unit

* Kostik Belousov <kostikbel@xxxxxxxxx> wrote:
- I've seen most drivers only use the device cloner, because they need
descriptor local storage. It turns out more drivers need this than I
initially thought. kib@ has a patch for this, so I hope this gets
committed one of these {days,weeks,months}.
The patch was committed ~ a week ago.

Great. Looks like I wasn't paying attention back then.

- After we've got file descriptor local storage, I think we can live
without the cloner. This means we could consider removing the minor
number argument from make_dev(), removing the unique unit number
restriction we currently have inside devfs, which causes many drivers
to use number pools for no obvious reason.
I think we cannot live without clones regardless of devfs_cdevpriv.
The model assumed for the pty, snp and probably several other devices
actually requires new cdev instead of the priv data.

The pty driver does not use the clone_* interface. It only uses the
eventhandler, which should indeed be left intact. The snp driver does
use the clone_* interface, but not in a way that can't be done using the
eventhandler, validating the device name and calling make_dev()
directly.

Please take a look at src/usr.sbin/watch/watch.c:open_snp(). We might as
well turn snp(4) into a single /dev/snp, where the kernel space driver
uses per-descriptor data to distinguish the instances. This provides
some advantages:

- No more silly open()-loops.

- A system administrator can change the permissions on /dev/snp, which
automatically sets a system wide policy, instead on one of the device
nodes.

- We don't fill up the system with a lot of unused nodes.

for i in `seq 1000`
do
ls /dev/bpf$i > /dev/null
done

I was thinking about discussing this patch with my mentor + committing
it somewhere in the nearby future. Any comments?

Making minor == unit number looks to be not a bad idea, please, look at
the saga of the tty_pty.c revs. 1.153, 156, 1.157. Making the devices use
si_drv0 directly probably is not so good since we remove the indirection
layer that is already present and allows for some (minor) freedom in the
devfs/kern_conf implementation.

But why isn't this done for si_drv1 and si_drv2 then? My idea is to turn
si_drv0 in an integer field that can be freely used. There is reason to
force a policy on this field.

--
Ed Schouten <ed@xxxxxxxx>
WWW: http://80386.nl/

Attachment: pgpWYxrpsm59A.pgp
Description: PGP signature

Relevant Pages

  • Re: [PATCH] uio: User IRQ Mode
    ... In this mode the user space driver ... is responsible for acknowledging and re-enabling the interrupt. ... This can easily be done without your patch. ...
    (Linux-Kernel)
  • Re: [PATCH] Blackfin: blackfin on-chip SPI controller driver
    ... patch, rather than initial-plus-cleanups. ... Please put this in Kconfig up with the other SPI controller drivers, ... relevant points in the driver. ... place to reverse any DMA mappings ... ...
    (Linux-Kernel)
  • Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
    ... To build your new patch for ARM I have modified the line "depends on ... configured that driver as a module. ... As for the RTC patch, it does work on the shark, and is needed. ...
    (Linux-Kernel)
  • [PATCH] interrupt driven hvc_console as vio device (final)
    ... Here is the revised hvc_console patch which fixes the issues you were ... This is an hvc_console patch which provides driver and ppc64 ... console output functionality prior to early console init (pre mem init ... -Added early discovery of vterm/vty adapters by doing a bus walk on ...
    (Linux-Kernel)
  • Re: [PATCH 0/4, v14] PCI, ACPI: Physical PCI slot objects
    ... To emulate the platform that assigns the same name to multiple ... With this patch, I ... varies depending on whether pci_slot driver is loaded or not. ... I got the following error message when I loaded pciehp driver. ...
    (Linux-Kernel)