On Mon, Aug 24, 2020 at 5:30 PM Christian Schoenebeck <qemu_oss@xxxxxxxxxxxxx> wrote: > > Hu, you're right! There is indeed a somewhat congruent effort & discussion > going on in parallel. Pulling in Miklos into CC for that reason: > https://lore.kernel.org/lkml/CAJfpegtNP8rQSS4Z14Ja4x-TOnejdhDRTsmmDD-Cccy2pkfVVw@xxxxxxxxxxxxxx/ > > However the motivation of that other thread's PR was rather a procfs-like > system as a unified way to retrieve implementation specific info from an > underlying fs, and the file fork aspect would just be a 'side product'. The motivation is a consistent interface for accessing file related data, whatever that be. > But as they already pointed out, it would be a problem to actually agree about > a delimiter between the filename and the fork name portion. Miklos suggested a > a double/triple slash, but I agree with other ones that this would render > misbehaviours with all sorts of existing applications: > https://lore.kernel.org/lkml/c013f32e-3931-f832-5857-2537a0b3d634@xxxxxxxxxxxxxxxx/ That argument starts like this: - Path resolution has allowed multiple slashes in UNIX systems for 50 years, so everyone got used to building paths by concatenating things ending in slashes and beginning in slashes and putting more slashes in the middle. This can't be argued with, we probably have to live with that for 50 more years (if we are lucky). The argument continues so: - Because everyone got lazy, we can't introduce a new interface with new rules, because all those lazy programmers won't be bothered to fix their ways and will use the old practices while trying to use the new interface, which will break their new apps. Huh? Can't they just fix those broken apps, then? Yeah, yeah, I know it's not as simple as that, as the path can come from application A, while the new interface is used by application B. But this would only be a real backward compatibility issue if the new interface is used without consideration for such cases (i.e. clean up paths coming from untrusted sources before using it with the new interface). So no, I don't buy that argument. Anyway, starting with just path resolution starting at the target file makes sense as a first step. The most important thing, I think, is to not fragment the interface further. So O_ALT should allow not just one application (like ADS) but should have a top level directory for selecting between the various data sources. Thanks, Miklos
