Jim Sibley writes: > When will SuSE have the devfs as the default for zSeries so we don't > have to compile the kernel to use it and get away from the double > mapping we have to do between device and device node? It is a real > nuisance to try and map 100 devices per LPAR for 7 or 8 LPARs. Then try > moving 20 or thirty of those volumes to another LPAR when business > needs dictate! W/O devfs, I can vouch that it is both a pain and error > prone.
devfs is not the only way of handling these device management issues. devfs carries along with it a certain amount of design and implementation "history". Let's just say that distributions wouldn't gratuitously omit it just to make your life harder. There are two issues: the cleanliness of the kernel side and device management in userland. They only overlap slightly. In the medium to long term, the "stick together multiple majors and index everything into arrays of stuff" issue on kernel side should be solved via the combination of 32-bit dev_t (12 bit major, 20 bit minor), nice struct device, struct gendisk or whatever and devicefs. This assumes that Al Viro and co make the scramble before the 2.5 feature freeze next week (or get it in afterwards anyway :-). Linus gave him the OK two weeks ago so I have high hopes. For the userland issue, I've often wondered why someone hasn't done a version of scsidev for z/Linux (presumably "dasddev" would be the obvious name). It would simply go look at all the DASD information available via /proc/dasd/devices, /proc/partitions, query all the volumes for their volsers and build up a set of nodes and symlinks so you can refer to your volumes by label, /dev/dasdvol/VLABEL, or devno, /dev/dasdno/2345 and so on. I must admit, I haven't quite wondered hard enough for it to reach the top of my todo list though... --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself
