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 earlie
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 f
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 f
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
-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
: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
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
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 sequen
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 l
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,
: >
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
: ..
:
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
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 t
On Sat, 15 Nov 2003, Garance A Drosihn wrote:
> 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 nu
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 releas
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 ea
:> 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
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
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 t
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
: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:
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 p
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 i
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 x11/nvi
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
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 els
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
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 t
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 t
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 t
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
> 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 (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: exite
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
http://lists.freebsd.o
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 th
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 k
39 matches
Mail list logo