On Wed, 2023-01-11 at 14:17 +0100, Hannes Reinecke wrote: > On 1/11/23 13:55, James Bottomley wrote: > > On Wed, 2023-01-11 at 12:49 +0100, Hannes Reinecke wrote: > > > Hi all, > > > > > > given the recent discussion on the mailing list I would like to > > > propose a topic for LSF/MM: > > > > > > Limits of development > > > > > > In recent times quite some development efforts were left > > > floundering (Non-Po2 zones, NVMe dispersed namespaces), while > > > others (like blk-snap) went ahead. And it's hard to figure out > > > why some projects are deemed 'good', and others 'bad'. > > > > It's not any form of secret: some ideas are just easier to > > implement and lead to useful features and others don't. It's > > exactly why we insist on code based discussions. It's also why > > standards that aren't driven by implementations can be problematic: > > what sounds good on paper doesn't necessarily work out well in > > practice. > > > But that's kinda the point. > The above quoted examples do have implementations which were sent to > the mailing list (well, not the dispersed namespace one, but let's > not get hooked up on that one), _and_ enable existing hardware > features. > So they tick all the boxes you specified. > Yet they have been rejected. Because they don't provide much benefit once implemented and the implementation is a bit many tentacled. The point of implementation driven specs isn't to declare it's great when you get to any old implementation, however horrible, just because you can force one of your employees to produce it, it's to fail fast and do something better when the implementation proves problematic. The kernel patch process can provide the failure, but it's much less traumatic if the original implementors recognize it before it gets spec'd. Just because something exists in hardware is no reason to use it as the fact that we use < 10% of the SCSI spec most hardware speaks will attest. James
