Just as I thought - Linux is more interested in some notion of "cleanliness" rather than real user problems! devfs has already been coded and is available for zSeries users who need some relief. I've been struggling with this idiotic dev node system for 2 years on up to 40 linux LPARS and I can tell you from hard experience that "niceness" and what might happen in the future hasn't been the least bit of help in dealing with several thousands devices. Excuse the frankness but the linux solution is neither clean or easy to use IMNSHO.
The net effect of this linux approach, in reality, is that all machines should look like a PCs rather than Linux being flexible enough to provide special solutions for special problems. Enough said. On Monday, Oct 14, 2002, at 03:06 US/Pacific, Malcolm Beattie wrote: > 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 >
