Piercarlo Grandi writes:
> I have started using 'devfs' quite recently (kernel 2.4.6), as I was
> scandalized by the number of entries in '/dev/' in most common
> distributions (my current SuSE 7.2 has over 2,000, Mandrake 7.1 had over
> 6,000), as you probably were when you decided to write 'devfs'.
>
> I think it's fine, but there are some small details...
>
> * One thing that did bite me is that entries under 'discs/', 'cdroms/'
> and 'tapes/' are not numbered, as suggested in the FAQ, consecutively
> starting from zero; right now I have 'cdrom0' and 'cdrom2', and at
> some point I had 'tape1' and 'tape5', for example.
>
> It seems to depend on whether the number of times the modules related
> to the devices have been loaded/unloaded.
Yes. Fixed in kernel 2.4.7.
> * Another possible bug: in the manuals page for 'devfsd' in the section
> 'CAVEATS' you mention the danger of using a ``devname'' like "cdrom",
> as it is not anchored by either/both '^' or '$'.
>
> However the sample 'devfsd.conf' and some of examples in the FAQ use
> similarly dangerous syntax. I have rewritten these REs in what I think
> is a safer/nicer way (down to details like replacing '.*' with '^.'),
> making essentially all ``devnames'' start with the '^' anchor, which I
> think should be the case. I have attached it.
Argh! You've changed it from a generic config file to something quite
specific. Thus the patch is huge. If you want to send a patch to add
anchors to the sample config file, don't include your own
personalisations. That's no help to me. Grab a fresh copy of the
sample config file and edit that.
Patch rejected.
> * The documentation is rather vague on what a regular expression is
> (there are _many_ flavours) and what kind of syntax the 'devfsd'
> configuration files can have; for example it is not clear if names
> with blanks or other special characters can be specified in
> '/etc/devfsd.conf'.
Blanks are not allowed. Control characters are discouraged.
> * Against your advice :-), I do use entries like '/dev/modem',
> '/dev/tape', '/dev/cdrom'; I have attached a sample file that sets
> them up. I use 'COPY' for brevity. It would be nice to have built in
> 'SYMLINK', and 'UNLINK' actions, as the 'CFUNCTION' alternative seems
> to crash my 'devfsd'.
Try devfsd-v1.3.12.
> * In any case I usually dislike symbolic links, for various practical
> and philosophical reasons; it would be nice if the 'MK{OLD,NEW}COMPAT'
> actions could optionally make hard links instead of symbolic links...
>
> This would also help in getting OLDCOMPAT or NEWCOMPAT names in
> '/proc/mounts' and other places instead of the very verbose kernel
> names.
>
> It seems to me that hard links should be really very easy to add; I
> just had a look at 'fs/devfs/base.c' and this seems indeed the
> case. Any subtle reasons why such a typical UNIX thingie is not
> supported?
Yes: it would make devfs a lot more complicated. Hard links are
actually harder to add than you think.
> * It might be rather useful if 'devfs', whether or not was mounted as
> '/dev' or not, always mounted itself as '/proc/dev', as this would be
> both logically appropriate and easy to rely upon.
Nope. No more crap in /proc!
> * It would be nice if you kept a page (or may I could) with a list of
> applications that are use the old names, and possible workarounds.
If you have time to track the applications that have been changed and
those that still need to be changed, then please go ahead and write a
WWW page. Send me the URL so I can point to it.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|