-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 14 Nov 2003 08:33, Matt Smith wrote:
And gnomevfs was something I saw in another headsup. There are bound to
be others, I'm just keeping an eye on my /var/log/messages to see if
anything else sig 11 or 12's! So far so good though.
I
On Tue, Nov 18, 2003 at 12:44:35PM +, Mark Dixon wrote:
On Friday 14 Nov 2003 08:33, Matt Smith wrote:
And gnomevfs was something I saw in another headsup. There are bound to
be others, I'm just keeping an eye on my /var/log/messages to see if
anything else sig 11 or 12's! So far so
Kirk McKusick wrote (2003/11/14):
This is why we make this change now so that it will be in place
for the masses when 5.2 is released :-)
Hello, and is it possible to review some my (one's from masses :o)
questions/suggestions?
* cvtstatfs() for freebsd4_* compat syscalls does not copy text
On Tue, 18 Nov 2003, Rudolf Cejka wrote:
Hello, and is it possible to review some my (one's from masses :o)
questions/suggestions?
* cvtstatfs() for freebsd4_* compat syscalls does not copy text fields
correctly, so old binaries with new kernel know just about first
16 characters from
On Fri, Nov 14, 2003 at 08:33:06AM +, 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)
I think this was reported earlier, but
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 like
: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
At 12:21 AM -0500 11/16/03, Jeff Roberson wrote:
On Sat, 15 Nov 2003, Garance A Drosihn wrote:
Or maybe the real problem is that we claim that there will
be no API/ABI changes after X.0-RELEASE, and we've really
missed that mark with 5.0-RELEASE, for a variety of reasons.
If we're going to
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:
pid
: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
Daniel Eischen wrote:
On Fri, 14 Nov 2003, Andrew Gallatin wrote:
Can't we bump the libc version so that dynamically linked, non-system
binaries can continue to work? Having things like postfix and gnome
dumping core seems excessivly bumpy. Upgrading all ports is a pain.
I don't think
Robert Watson wrote:
What's going on is the following: while we have a compatibility system
call in place, it only affects applications linked against non-current
libc. As soon as you recompile libc, applications expecting the old
statfs() ABI get the new statfs(), and depending on where
On Sat, Nov 15, 2003 at 02:45:57PM -0800, Terry Lambert wrote:
For 6.0, can we start off libc at libc.so.MMDD and move it
back to libc.so.6 for the first release? That way we can bump
it whenever we want to avoid the bumpy rides for -current
folk.
This is a great idea!
Provided
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
: 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 userland
On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
Provided that we
2. replace the date with a convenient sequence number, which we can
call the minor version number, and
..
E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...
Please no -- it wouldn't be easy
At 6:20 PM -0800 11/15/03, David O'Brien wrote:
On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
Provided that we
2. replace the date with a convenient sequence number,
which we can call the minor version number, and
..
E.g.: libc.so.6.0, libc.so.6.1, and (first release)
On Sat, Nov 15, 2003 at 11:05:51PM -0500, Garance A Drosihn wrote:
Or maybe the real problem is that we claim that there will
be no API/ABI changes after X.0-RELEASE, and we've really
missed that mark with 5.0-RELEASE, for a variety of reasons.
Where do we claim that?
All I'm aware of is the
On Sat, 15 Nov 2003, Marcel Moolenaar wrote:
On Sat, Nov 15, 2003 at 02:45:57PM -0800, Terry Lambert wrote:
For 6.0, can we start off libc at libc.so.MMDD and move it
back to libc.so.6 for the first release? That way we can bump
it whenever we want to avoid the bumpy rides for
In message: [EMAIL PROTECTED]
David O'Brien [EMAIL PROTECTED] writes:
: On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
: Provided that we
: 2. replace the date with a convenient sequence number, which we can
: call the minor version number, and
: ..
: E.g.:
In message: [EMAIL PROTECTED]
Garance A Drosihn [EMAIL PROTECTED] writes:
: At 6:20 PM -0800 11/15/03, David O'Brien wrote:
: On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
: Provided that we
:2. replace the date with a convenient sequence number,
: which
In message: [EMAIL PROTECTED]
Daniel Eischen [EMAIL PROTECTED] writes:
: On Sat, 15 Nov 2003, Marcel Moolenaar wrote:
:
: On Sat, Nov 15, 2003 at 02:45:57PM -0800, Terry Lambert wrote:
:
:For 6.0, can we start off libc at libc.so.MMDD and move it
:back to libc.so.6 for
On Sat, Nov 15, 2003 at 11:17:00PM -0700, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
David O'Brien [EMAIL PROTECTED] writes:
: On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
: Provided that we
: 2. replace the date with a convenient sequence number,
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:
pid 4049 (smtpd), uid 1003:
Date: Fri, 14 Nov 2003 08:33:06 +
From: Matt Smith [EMAIL PROTECTED]
To: Marco Wertejuk [EMAIL PROTECTED]
Cc: Kirk McKusick [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: HEADS-UP new statfs structure
X-ASK-Info: Whitelist match
Marco Wertejuk wrote:
Just for a short note: cfsd
Kirk McKusick writes:
And mail/postfix and devel/gnomevfs2 (ones's i've found so far)
...
This is why we make this change now so that it will be in place
for the masses when 5.2 is released :-)
Can't we bump the libc version so that dynamically linked, non-system
binaries can
On Fri, Nov 14, 2003 at 08:33:06AM +, 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
Bruce Cran wrote:
On Fri, Nov 14, 2003 at 08:33:06AM +, 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
On Fri, 14 Nov 2003, Andrew Gallatin wrote:
Kirk McKusick writes:
And mail/postfix and devel/gnomevfs2 (ones's i've found so far)
...
This is why we make this change now so that it will be in place
for the masses when 5.2 is released :-)
Can't we bump the libc version so
Daniel Eischen writes:
On Fri, 14 Nov 2003, Andrew Gallatin wrote:
Kirk McKusick writes:
And mail/postfix and devel/gnomevfs2 (ones's i've found so far)
...
This is why we make this change now so that it will be in place
for the masses when 5.2 is
On 2003-11-14 21:50 +, Matt Smith wrote:
The only thing I've found a problem with so far is postfix as I've
mentioned.
Matt.
While attempting a portupgrade of postfix, I realized ruby core dumps
after the statfs stuff too (even after I rebuilt it). I'm a bit puzzled,
anyone else
On Fri, 14 Nov 2003, Munish Chopra wrote:
On 2003-11-14 21:50 +, Matt Smith wrote:
The only thing I've found a problem with so far is postfix as I've
mentioned.
While attempting a portupgrade of postfix, I realized ruby core dumps
after the statfs stuff too (even after I rebuilt
On Fri, 2003-11-14 at 22:46, Bruce Cran wrote:
Either the new statfs, or something in a recent change in -CURRENT
(since last week), has broken the nvidia driver.
I've been using it now for
over half a year with no problems at all. I installed the new kernel
and world, rebuilt
At 5:26 PM -0500 11/14/03, Robert Watson wrote:
As soon as you recompile libc, applications expecting the old
statfs() ABI get the new statfs(), and depending on where their
smaller struct statfs is located, may stomp on memory they're
using for something else (like critical data structures).
But
On Sat, 15 Nov 2003 00:46:19 +0100, Sascha Holzleiter
[EMAIL PROTECTED] wrote:
On Fri, 2003-11-14 at 22:46, Bruce Cran wrote:
Either the new statfs, or something in a recent change in -CURRENT
(since last week), has broken the nvidia driver.
I've been using it now for
over half a year with no
Just for a short note: cfsd (ports/security/cfs) should be
recompiled as well after those statfs changes.
--
Mit freundlichen Gruessen,
Marco Wertejuk - mwcis.com
Consulting Internet Solutions
___
[EMAIL PROTECTED] mailing list
The statfs structure was updated on Nov 11th with 64-bit fields
to allow accurate reporting of multi-terabyte filesystem sizes.
You should build and boot a new kernel BEFORE doing a `make world'
as the new kernel will know about binaries using the old statfs
structure, but an old kernel will not
On Wed, 12 Nov 2003, Kirk McKusick wrote:
The statfs structure was updated on Nov 11th with 64-bit fields
to allow accurate reporting of multi-terabyte filesystem sizes.
You should build and boot a new kernel BEFORE doing a `make world'
as the new kernel will know about binaries using the
38 matches
Mail list logo
