devfs/devfsd :registers generic (sg) while cd (sr_mod) was not. Still investigating.

Some time ago, I posted my question concerning devfs/devfsd in 2.4.2 registering "generic" name offered by sg module while "cd" offered by sr_mod.o was not registered for my SCSI CDs. Namely, I needed to load "sr_mod.o" somehow on my own while "sg" seemed to be loaded for no apparent reason.

Re: devfs/devfsd :registers generic (sg) while cd (sr_mod) was not. Still investigating.

Chiaki, Wow! This is proving a very time consuming problem. There is one small question I can answer: Ishikawa wrote: [snip] subtle differences the way devfs is handled Why does sg.c use write_lock_irqsave() while sr.c does not? The lock is there because st and sg have got rid of the

Re: devfs/devfsd :registers generic (sg) while cd (sr_mod) was not. Stillinvestigating.

I was trying to figoure out "WHY" sg was loaded since I was not asking for it and /etc/init.d/* scripts seemed not to. I would think a prudent first step in tracking this down would be to chop out parts of the init processing until sg.o no longer gets loaded at initialization time, and thus

Re: devfs/devfsd :registers generic (sg) while cd (sr_mod) was not. Still investigating.

Doug, Thank you for the enlightment about write_lock_irqsave(). Regarding who is doing sg loading, I will try your suggestions over the weekend to find out. Knowing what the current task and its parent task seem to be a great help in analyzing the system behavior and learning aid. (I wonder