[lkml]   [2001]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ramfs problem... (unlink of sparse file in "D" state)

On Mon, 8 Jan 2001, Alan Cox wrote:

> > Which happens to be remarkably ugly. And it will not get better tomoorow...
> Its really only ugly in one way which is that you pass an int for the item
> rather than having a struct of all the data

You know as well as I do that as soon as we add it glibc folks _will_
start whin^Wasking for "just one more field". So structure is out of
question for pretty obvious reasons... Wanna bet that they'll ask for
maximal size of symlink that could be created in directory? Or truncate
long names vs. reject long names policy. And everything from /proc/mounts,
since "binary data is easier to parse". And case sensitivity. And
NLS used. And timezone of that filesystem. And SGID policy (BSD vs. SysV).
And subset of mode bits available on that fs. And ability to create
device nodes. And... There is a lot of crap that could be asked for.
General rule with GNU seems to be that _every_ piece of crap somebody
had thought about gets tossed into the mix.

* Any attempt to decide on a fixed structure will generate a flamewar,
where everyone and his mom will advocate their pet features.
* There will be regular requests to play syscall of the week game.
I.e. new version of pathconf(2) that will support more new features. Old
ones will not go away, indeed.
* There will be regular requests to make syscall versioned (read:
magic number + pointer to structure with layout depending on that number).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.066 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site