:Well, there's some glue there now, but its pretty slim. What you
:advocate would swap system call numbers for doing structure reloading per
:call, which would significantly incrase the cost of the call.
:Considering that *BSD system call overhead is pretty bad as is, I don't
:think I'd be puttin
On Sat, 15 Nov 2003, Matthew Dillon wrote:
> I don't understand the question. All that happens is that functions like
> fstat() and statfs() become libc functions rather then direct syscalls.
> The userland program doesn't know the difference, it uses fstat() and
> statfs() just l
:> sense to do it.
:
:How do you propose to achieve POSIX compliance? At the library
:level? Or "not at all"?
:
:-- Terry
I don't understand the question. All that happens is that functions like
fstat() and statfs() become libc functions rather then direct syscalls.
The userlan
Matthew Dillon wrote:
> I recommend that instead of rolling these sorts of system calls over
> and over again (how many versions of stat do we have now? A lot!),
> that instead you make a system call which returns a capability buffer
> and then have libc load the capabilities it un
:Expect to have to recompile the entire fricking world for a change
:this fundamental.
:
:Really, what should have appened is that the system call interface
:for stat should have been retired as "ostat", a new system call
:interface introduced, and the libc version number bumped, given a
:change th
Matt Smith wrote:
> Marco Wertejuk wrote:
> > Just for a short note: cfsd (ports/security/cfs) should be
> > recompiled as well after those statfs changes.
>
> And mail/postfix and devel/gnomevfs2 (ones's i've found so far)
>
> postfix did this every time it received a mail until I recompiled it:
