On 9/2/07, Joel C. Salomon <[EMAIL PROTECTED]> wrote: > On 9/1/07, Uriel <[EMAIL PROTECTED]> wrote: > > With this way of thinking we will never catch up with lunix's 400 > > syscalls (and counting, not to mention the ioctls)! > > We're partly there in spirit; what fraction of the 4e kernel's system > calls are there for backwards compatibility? ;) > > Back on topic, I wasn't proposing a readdir() syscall but pointing out > that Douglas's suggestion would not in fact be painless or transparent > under Plan 9.
Indeed, and I would say that is a feature, not a bug. (Adding an extra syscall to read dirs would be a bug). But maybe my sarcasm got lost along the way. And actually, I think one could have something similar to Douglas suggestion in Plan 9 without changing the kernel or the vfs, or even the file servers, just have a stackable file server which for every original file /foo.txt allows you to access a /[EMAIL PROTECTED]/ dir where all the extended attributes or whatever can live, that would even keep backwards compatibility with all existing tools (tools that don't know about @extendedjunk/ dirs would not even see them unless they explicitly walk to them, so you could use cd /[EMAIL PROTECTED]/, followed of ls and cat to inspect the attributes, but if you do cat /* or ls / you would get a sensible output. Anyway, I still think it would be a waste of time, but like unix in its day, plan9 makes adding new 'features' rather easy, whatever they are worthy or another symlink-hell awaiting to happen is another question. Best wishes uriel P.S.: The Plan 9 industry is not creating enough jobs, we need more syscalls! And dynamic linking!
