It seems that just about everything that uses devfs
contains some logic that attempts to construct an unused
device name with something like:
static devnum = 0;
sprintf (name, "lp%d", devnum++);
devfs_register_device(..., name,...);
Besides duplicating a lot of logic, making devfs support
more of a pain to add and uglier to look at, the numbering behvior
of these drivers can be inconsistent, especially if some devices
are being removed. For example, as I insert and remove my PCMCIA
flash card, it becomes /dev/discs/disc1, /dev/discs/disc2,
/dev/discs/disc3, etc.
I propose to change the devfs registration functions
to allow registrations of devices ending in %d or %u, in which
case it will use the first value, starting at 0, that generates a
string that already registered. So, if I have disc0, disc1, and disc2,
and I remove the device containing disc1, then disc1 will be next
disc device name to be registered, then disc3, then disc4, etc.
Just to illustrate, I have attached a patch that should
do it for device files, but I also want to do this for symlinks and
possibly directories. So, I am not suggesting that anyone should
integrate this patch yet.
This will make it a bit simpler to add devfs support to
the remaining drivers that do not have it, and it will make
numbering within devfs much simpler by default. Of course, drivers
that want to do their own thing the current way would not be impeded
from doing so by this change.
Anyhow, I thought I should post this suggestion to see if
anyone has any objections, better ideas, improvements or comments.
--
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
On Sun, 24 Dec 2000, Adam J. Richter wrote:
> I propose to change the devfs registration functions
> to allow registrations of devices ending in %d or %u, in which
> case it will use the first value, starting at 0, that generates a
> string that already registered. So, if I have disc0, disc1, and disc2,
> and I remove the device containing disc1, then disc1 will be next
> disc device name to be registered, then disc3, then disc4, etc.
i use devfs for my computers and i agree that the quasi-consistancy of
device naming is annoying. my example is with my scsi zip ext. drive.
when i insert a FAT formatted disc with a PC partition table, the partition
i want to mount is part1. when i insert a HFS formatted disc with a MAC
partition table, the partition i want to mount is part4. this is very ugly,
having to set up two entries in fstab for the same device. instead of
messing around with the naming behavior, why not add configuartion options
to the devfsd daemon? they could be per-driver/host/device. maybe i just
don't see how to do it with the existing system. in the meantime i am just
setting up a /dev/mntsym/ directory that has symlinks "zip" "cdrom" "dvd",
etc. when the appropriate modules register, as a quick hack until this is
resolved.
> This will make it a bit simpler to add devfs support to
> the remaining drivers that do not have it, and it will make
> numbering within devfs much simpler by default. Of course, drivers
> that want to do their own thing the current way would not be impeded
> from doing so by this change.
it is my opinion that drivers should not have to be too specific about
where their representitive /dev entries end up. i don't know enough about
internals, but there must be a way to unify the registration of device
entries. make the drivers register with the devfs system with the default
informations and specifications, and let the devfs system make those dumb
null entries or what ever else. it would be yet another layer of
abstraction, but it might help make the devfs more flexible.
sidenote: i got a new laptop with a serial port and lots of unsupported
hardware. i went to work hacking away at what i could. i noticed especially
with devfs, that debugging serial port like /dev/tts/0 is impossible if the
serial.o driver refuses to load due to an IRQ conflict. if the driver never
registers/auto_config's, the /dev/tts entries are not there to use. this
is of concern, since some device names should be created regardless of
whether the device is loaded or not. without the device entries for serial
ports i was not able to give 'setserial' or 'stty' a proper device name for
the ports. the PCI standards committee slacked off on the PCI serial spec,
it is really weak for standards on devices like modems. the serial port is
a (Xircom MPCI 56) Toshiba internal PCI modem 56, a real modem like i
always thought would be supported by the serial driver, and yet sits unused
like the winmodems i was careful to avoid.
that's my dime-and-a-quarter.
Eric Shattow
[email protected]
Eric Shattow wrote:
[snip]
> when i insert a FAT formatted disc with a PC partition table, the partition
> i want to mount is part1. when i insert a HFS formatted disc with a MAC
> partition table, the partition i want to mount is part4. this is very ugly,
and it has nothing to do with devfs. Those would be /dev/sda1 (adjust
device name for IDE instead of SCSI, etc.) and /dev/sda4 without devfs.
In this case, the problem is that different Zip disks really do have their
data on different partitions. (If you use enough different disks and
formatting utilities, it won't even be the same partition for all PC disks
or all Mac disks, IIRC.) I don't use Zip disks much anymore, although
there's a similar phenomenon with my SCSI MO drive on my desktop Mac
(which I recently started using Linux on again).
What would be nice is if there were a way of saying, "here's the disk,
mount the Right Partition(tm) in /mnt/whatever." For all I know, maybe
someone's done that already. If not, it seems to me that a userspace
utility (== no extra kernel bloat) could parse the partition table and use
some heuristics or something to pick the partition to mount. (I'm probably
going to do other stuff instead of implementing this, but I haven't
decided for sure yet.) In any case, I think the solution would be
completely orthogonal to devfs...
-Barry K. Nathan <[email protected]>
On Sun, Dec 24, 2000 at 11:02:39PM -0800, Barry K. Nathan wrote:
> Eric Shattow wrote:
> [snip]
> > when i insert a FAT formatted disc with a PC partition table, the partition
> > i want to mount is part1. when i insert a HFS formatted disc with a MAC
> > partition table, the partition i want to mount is part4. this is very ugly,
>
> and it has nothing to do with devfs. Those would be /dev/sda1 (adjust
> device name for IDE instead of SCSI, etc.) and /dev/sda4 without devfs.
>
> In this case, the problem is that different Zip disks really do have their
> data on different partitions. (If you use enough different disks and
> formatting utilities, it won't even be the same partition for all PC disks
> or all Mac disks, IIRC.) I don't use Zip disks much anymore, although
> there's a similar phenomenon with my SCSI MO drive on my desktop Mac
> (which I recently started using Linux on again).
[snip]
And don't forget that IDE zip drives can be programmed to hide the
partition table altogether from the OS. Supposedly this can be changed
via an ATAPI command to the drive, but I don't think the kernel driver
has any support for this.