Hello, Karel. On Thu, Jan 13, 2011 at 02:26:37PM +0100, Karel Zak wrote: > > Yeah, sure, it's not like I can afford to avoid fixing it at this > > point anyway, but I still want to point out it's at the wrong layer > > and shouldn't have been added like this, really. If you want blkid to > > identify it, the proper thing to do would be querying blk device for > > the claimer and then use claimer-specific method to query them. It's > > It seems that dependencies (holders/slaves) between devices is pretty > generic thing. Why do you think that we need claimer-specific method? > The /sys filesystem is better that ictls in many ways. Because sysfs is already complex enough without representing dependency information without strictly defined strcture in it. It's for exporting the device tree to users. We have developed interesting ways to exploit it but it generally has proven to be a bad idea to add symlinks without clearly defined structure beneath it. People end up using them differently and often they don't understand how the kobject sysfs things are wired and it ends up with a lot of cruft exporting something which is designed by small number of people without really considering what's going on in the rest of the hierarchy. > > not like the current method would make sense for btrfs or whatnot. > > Could you be more verbose, please? If the symlinkery was something which could properly replace configuration and query, sure, let's standardize it and share it among all possible claimers of block devices, but it's not. md, dm, btrfs need to export and process way more information than can be represnted in these symlinks and it's there more as a pretty thing than anything which is actually necessary and useful. And the original implementation directly played with kobjects (in an unnecessarily complicated way too) and allowed any kobject to be linked. Things like that just never end up pretty. So, just don't do it. Sysfs is for device hierarchy. Don't try to shove pretty looking things there (unless it's something widely agreed on and necessary, of course). Thanks. -- tejun -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
