On Jul 6, 2005, at 2:50 PM, Poul-Henning Kamp wrote: > In message <20050706212043.GA6215_at_ns1.xcllnt.net>, Marcel Moolenaar > writes: > >> That would be better, yes. Would a slicer-specific API that's >> implemented in terms of g_ctl be welcome in libgeom? It would >> help convert the existing tools to use GEOM more directly, >> which helps the convergence of the functionality into a single >> tool: geom(8). For geom(8) it would then probably be a class >> library, right? > > My worry about this is that the "DWIM" aspect will render most > generic stuff obsolete. Doesn't that depend entirely on having the necessary abstractions and having those translated to hard "currency" at the right time? Where "the right time" is not too soon (i.e. at a level too high, say the UI) or too late (i.e. at a level to low, say the hardware driver). > For instance, in a MBR, if I say > "create ad0s3 max" > in order to use the largest free slap of space, that end sector > number should be rounded down to a cylinder boundary and the start > sector number to a track boundary if it would otherwise occupy the > first track. But this example merely demonstrates that sizes and offsets are subject to normalization at the slicer level and that any attempt to conclude anything at the levels above it prior to the normalization is moot. It doesn't show that "create ad0s3 max" can not be implemented using a generic API. If you add a normalization function to the API that lets slicers round up or round down based on geometry constraints, then at the higher levels you don't have to worry about it (other than making sure that you work with normalized values). We already have the magic in libdisk. We only need to beef up the interface so that it isn't only usable by sysinstall. This might be a good way to prototype and work towards a common API and a common tool. -- Marcel Moolenaar USPA: A-39004 marcel_at_xcllnt.netReceived on Wed Jul 06 2005 - 21:59:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:38 UTC