devfs
[Top] [All Lists]

Re: modules.devfsd needs /dev/scsi/*/part* handling

To: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
Subject: Re: modules.devfsd needs /dev/scsi/*/part* handling
From: Thierry Vignaud <tvignaud@xxxxxxxxxxxxxxxx>
Date: Wed, 16 Jan 2002 00:23:59 +0100
Cc: Borsenkow Andrej <Andrej.Borsenkow@xxxxxxxxxxxxxx>, devfs mailing list <devfs@xxxxxxxxxxx>
In-reply-to: <200201150628.g0F6SQf06569@xxxxxxxxxxxxxxxxxxxxxxxx> (Richard Gooch's message of "Mon, 14 Jan 2002 23:28:26 -0700")
Organization: MandrakeSoft
References: <1008885491.6464.4.camel@xxxxxxxxxxxxxxxxxxxxx> <200201150628.g0F6SQf06569@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-devfs@xxxxxxxxxxx
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1
Richard Gooch <rgooch@xxxxxxxxxxxxxxx> writes:

> > I was just surprised why my Jaz on parallel port (ppa adapter) never
>> appears. It turned out, after desperate fight with symlinks I finally
>> changed fstab to point to canonical name -
>> /dev/scsi/host0/bus0/target4/lun0/part4. But these names are not handled
>> by modules.devfs so sd_mod was never loaded.
>> 
>> There is handling for /dev/sd/* (that I had before). But it is just a
>> symlink and after eject it gets lost and when you try to access it again
>> sd_mod is already loaded so nothing happens (i.e. new media is not
>> rescanned for partition info). There is handling for /dev/discs - but,
>> unfortunately, there is no fixed relation between physical address
>> (host/bus/target) and disc number - they are simply numbered after they
>> get registered so if you have several removables sometimes they get one
>> number sometimes other. And I want to be sure I always refer to correct
>> drive.
>> 
>> The imediate quick'n'dirty fix was to add 
>> 
>> alias     /dev/scsi*/part*              /dev/sd
>> 
>> to /etc/modules.devfs
>> 
>> Still, it looks like a part of more general problem. I begin to think
>> that devfsd has to treat LOOKUP for symlinks that are managed by devfsd
>> itdelf specially. I.e. when it gets request for /dev/sd/c0b0t4l0u4 it
>> _knows_ that it points to /dev/scsi/..../part4 so it _could_ translate
>> it into request to that canonical name so that devfs would start
>> partition table revalidation. Does it make sense? 
>
> The problem with this is that it requires more code. The MKNEWCOMPAT
> action translates from kernel names to names like /dev/sd/c0b0t0u0p1
> but there is no code to provide the reverse operation. There hasn't
> been a need for this. As people who watch this list know, I hate
> adding code to devfsd unless it's absolutely necessary :-)
>
> However, you can easily use the regular expression matching engine to
> translate /dev/sd/* names to /dev/scsi/* names. This is even something that
> could be placed into a sample configuration file that I could ship with
> devfsd. Feel free to send some sample configuration lines :-)

i'll be happy to add it it you send working config :-)

however, have you installed dynamics & hotplug ? they should take care of
amovible devices.


<Prev in Thread] Current Thread [Next in Thread>