> > Andrej or anybody else familiar with devfs. It's doing something that > while it is very good and very convenient, it's not working the way that > I remember previously. > > I made a new Lucent Tech winmodem rpm (up from 6.00b15 to 8.22a4). It > compiled with zero changes other than the version number. It installed > on a fresh 8.2 install (won't work for cooker since it's tied directly > to the kernel version number, but that's not my question). > > 1) install rpm. The postinstall script adds a line to modules.conf, > HUPs devfsd, then depmod -a. > 2) lsmod. The modules (ltmodem and ltserial) are not loaded. > 3) vdir /dev/modem. It shows modem -> tts/LT0
what is vdir? > 4) lsmod. The modules are now loaded. > > I don't remember devfs creating devices when I attempted to do a > directory of them? Trying to open, yes. But just a directory? > Obviously this was present in devfs at the time of 8.2, but I don't > remember it acting that way. I DO remember wondering if would create > the device just from a directory command back when 8.2 got released, but > as I recall, I actually had to attempt to open the device to make it > create the device file. > devfs does not create anything. It is driver that creates devices upon having been loaded. And driver is (attempted to be) loaded when devfs generates LOOKUP event for devfsd. And LOOKUP is generated on any attempt to lookup dentry ... which effectively means on every open-like operation including creat (which internally is implemented as open). The first thing kernel does on open is to lookup name. Any other flags (like O_CREATE) are tested after system knows if name exists or not. > In the same breath: could this just be the sign of a better written > devfs implementation in this driver? > For all I can tell is has always been so (sans possible bugs that I am not aware of). I guess due to different problems with devfsD (not kernel devfs) lookup events may have not been generated properly at some point. -andrej
