Borsenkow Andrej 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
:-)
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|