> I'm faced with, as part of my sdcard stack, solving *yet again* the > problem of handling labeling on the disk. (Somehow, disk labeling seems > to be the hardest part of writing a block driver! :-) > > I ran across the cmlb module, which *looks* like it will do almost > everything I want it to. (The only problem I saw being the fact that > the VTOC8 versus VTOC16 dependency and minor numbering schemes are not > exported via any public header... it looks like sd.c and cmlb.c use > different macros which serendipitously evaluate to the same values.) > > The code I'm developing will be in ON. > > The question I have is, should I attempt to just use cmlb? (It looks > like I will be the second consumer after sd.)
Really? Seems like cmdk and dad both use it in addition to sd. > Or am I better off writing my own partition/vtoc/label code here? Are > there dragons anywhere in the cmlb code that I should be aware of, or > which would make it unsuitable for use by anything other than sd? > (Architecturally, it *looks* clean, apart from the aforementioned > issues wrt minor numbers....) > > Btw, if anyone who "owns" cmlb can speak up, I'd be grateful... one > question is that if I use this, I presume I will need a contract for ARC? I'm certainly not the owner, but given that cmlb is short for "common label" and given that the goal of the code as per the CRs that introduced it was to eliminate duplicate code in target drivers dealing with labeling and geometry, it seems like a pretty good fit. -- meem _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
