Re: HEADS-UP new statfs structure
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 I couldn't find the e-mail. I just confirmed that OpenOffice ( editors/openoffice port ) also needs to be recompiled due to the statfs changes. I just ran it now and it crashed: (gdb) where #0 0x2860742b in osl_psz_getVolumeInformation () from /usr/local/OpenOffice.org1.0/program/libsal.so.3 -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 mount points - what do you think about the
> following patch? (Or maybe with even safer sizeof() - but I did not
> test it.)
Hmm, there were 2 bugs here:
- MFSNAMELEN was confused with MNAMELEN in some places. This gives
unterminated strings as well as excessively truncated strings.
- there were off-by-1 errors which would have given unterminated
strings even without the previous bug.
> --- sys/kern/vfs_syscalls.c.orig Sun Nov 16 11:12:09 2003
> +++ sys/kern/vfs_syscalls.c Sun Nov 16 11:56:07 2003
> @@ -645,11 +645,11 @@
> osp->f_syncreads = MIN(nsp->f_syncreads, LONG_MAX);
> osp->f_asyncreads = MIN(nsp->f_asyncreads, LONG_MAX);
> bcopy(nsp->f_fstypename, osp->f_fstypename,
> - MIN(MFSNAMELEN, OMNAMELEN));
> + MIN(MFSNAMELEN, OMFSNAMELEN - 1));
MFSNAMELEN didn't change, so there is currently only a logical problem
here. The -1 term could be moved outside of the MIN(). It works in
either place and would save duplicating the terminating NUL in the
unlikely event that the new name length becomes smaller than the old
one. I'm not sure which is clearest.
> bcopy(nsp->f_mntonname, osp->f_mntonname,
> - MIN(MFSNAMELEN, OMNAMELEN));
> + MIN(MNAMELEN, OMNAMELEN - 1));
Similarly, plus the larger bug. MNAMELEN increased from
(88 - 2 * sizeof(long)) to 88, so if it were used without the -1 in
the above, then mount point name lengths longer than the old value
would have been unterminated instead of truncated.
> bcopy(nsp->f_mntfromname, osp->f_mntfromname,
> - MIN(MFSNAMELEN, OMNAMELEN));
> + MIN(MNAMELEN, OMNAMELEN - 1));
Similarly.
> if (suser(td)) {
> osp->f_fsid.val[0] = osp->f_fsid.val[1] = 0;
> } else {
> ---
>
> * sys/compat/freebsd32/freebsd32_misc.c: If you look into copy_statfs(),
> you copy 88-byte strings into just 80-byte strings. Fortunately it seems
> that there are just overwritten spare fields and f_syncreads/f_asyncreads
> before they are set to the correct value. What about these patches, which
> furthermore are resistant to possible MFSNAMELEN change in the future?
> [I'm sorry, these patches are untested]
>
> --- sys/compat/freebsd32/freebsd32.h.orig Tue Nov 18 16:58:28 2003
> +++ sys/compat/freebsd32/freebsd32.h Tue Nov 18 16:59:36 2003
> @@ -75,6 +75,7 @@
> int32_t ru_nivcsw;
> };
>
> +#define FREEBSD32_MFSNAMELEN 16 /* length of type name including null */
> #define FREEBSD32_MNAMELEN(88 - 2 * sizeof(int32_t)) /* size of on/from
> name bufs */
>
MFSNAMELEN hasn't changed, so this part is cosmetic. But don't we now need
to clone all of this compatibility cruft for the new statfs()? Native
32-bit systems have both. Then MFSNAMELEN for this version should probably
be spelled OMFSNAMELEN.
> struct statfs32 {
> @@ -92,7 +93,7 @@
> int32_t f_flags;
> int32_t f_syncwrites;
> int32_t f_asyncwrites;
> - charf_fstypename[MFSNAMELEN];
> + charf_fstypename[FREEBSD32_MFSNAMELEN];
> charf_mntonname[FREEBSD32_MNAMELEN];
> int32_t f_syncreads;
> int32_t f_asyncreads;
> --- sys/compat/freebsd32/freebsd32_misc.c.origTue Nov 18 16:59:49 2003
> +++ sys/compat/freebsd32/freebsd32_misc.c Tue Nov 18 17:03:31 2003
> @@ -276,6 +276,7 @@
> static void
> copy_statfs(struct statfs *in, struct statfs32 *out)
> {
> + bzero(out, sizeof *out);
Yikes. All copied out structs that might have holes (i.e., all structs
unless you want to examine them in binary for every combination of
arch/compiler/etc) need to be bzero()ed like this, but there are no
bzero()'s in files in this directory.
> CP(*in, *out, f_bsize);
> CP(*in, *out, f_iosize);
> CP(*in, *out, f_blocks);
> @@ -290,14 +291,14 @@
> CP(*in, *out, f_flags);
> CP(*in, *out, f_syncwrites);
> CP(*in, *out, f_asyncwrites);
> - bcopy(in->f_fstypename,
> - out->f_fstypename, MFSNAMELEN);
> - bcopy(in->f_mntonname,
> - out->f_mntonname, MNAMELEN);
> + bcopy(in->f_fstypename, out->f_fstypename,
> + MIN(MFSNAMELEN, FREEBSD32_MFSNAMELEN - 1));
> + bcopy(in->f_mntonname, out->f_mntonname,
> + MIN(MNAMELEN, FREEBSD32_MNAMELEN - 1));
> CP(*in, *out, f_syncreads);
> CP(*in, *out, f_asyncreads);
> - bcopy(in->f_mntfromname,
> - out->f_mntfromname, MNAMELEN);
> + bcopy(in->f_mntfromname, out->f_mntfromname,
> + MIN(MNAMELEN, FREEBSD32_MNAMELEN - 1));
> }
>
> int
This seems to be correct except possibly for the style (placement of -1
and fixing the indentation of the continuation lines so that it is not
bug-for-bug com
Re: HEADS-UP new statfs structure
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 fields
correctly, so old binaries with new kernel know just about first
16 characters from mount points - what do you think about the
following patch? (Or maybe with even safer sizeof() - but I did not
test it.)
--- sys/kern/vfs_syscalls.c.origSun Nov 16 11:12:09 2003
+++ sys/kern/vfs_syscalls.c Sun Nov 16 11:56:07 2003
@@ -645,11 +645,11 @@
osp->f_syncreads = MIN(nsp->f_syncreads, LONG_MAX);
osp->f_asyncreads = MIN(nsp->f_asyncreads, LONG_MAX);
bcopy(nsp->f_fstypename, osp->f_fstypename,
- MIN(MFSNAMELEN, OMNAMELEN));
+ MIN(MFSNAMELEN, OMFSNAMELEN - 1));
bcopy(nsp->f_mntonname, osp->f_mntonname,
- MIN(MFSNAMELEN, OMNAMELEN));
+ MIN(MNAMELEN, OMNAMELEN - 1));
bcopy(nsp->f_mntfromname, osp->f_mntfromname,
- MIN(MFSNAMELEN, OMNAMELEN));
+ MIN(MNAMELEN, OMNAMELEN - 1));
if (suser(td)) {
osp->f_fsid.val[0] = osp->f_fsid.val[1] = 0;
} else {
---
* sys/compat/freebsd32/freebsd32_misc.c: If you look into copy_statfs(),
you copy 88-byte strings into just 80-byte strings. Fortunately it seems
that there are just overwritten spare fields and f_syncreads/f_asyncreads
before they are set to the correct value. What about these patches, which
furthermore are resistant to possible MFSNAMELEN change in the future?
[I'm sorry, these patches are untested]
--- sys/compat/freebsd32/freebsd32.h.orig Tue Nov 18 16:58:28 2003
+++ sys/compat/freebsd32/freebsd32.hTue Nov 18 16:59:36 2003
@@ -75,6 +75,7 @@
int32_t ru_nivcsw;
};
+#define FREEBSD32_MFSNAMELEN 16 /* length of type name including null */
#define FREEBSD32_MNAMELEN(88 - 2 * sizeof(int32_t)) /* size of on/from name
bufs */
struct statfs32 {
@@ -92,7 +93,7 @@
int32_t f_flags;
int32_t f_syncwrites;
int32_t f_asyncwrites;
- charf_fstypename[MFSNAMELEN];
+ charf_fstypename[FREEBSD32_MFSNAMELEN];
charf_mntonname[FREEBSD32_MNAMELEN];
int32_t f_syncreads;
int32_t f_asyncreads;
--- sys/compat/freebsd32/freebsd32_misc.c.orig Tue Nov 18 16:59:49 2003
+++ sys/compat/freebsd32/freebsd32_misc.c Tue Nov 18 17:03:31 2003
@@ -276,6 +276,7 @@
static void
copy_statfs(struct statfs *in, struct statfs32 *out)
{
+ bzero(out, sizeof *out);
CP(*in, *out, f_bsize);
CP(*in, *out, f_iosize);
CP(*in, *out, f_blocks);
@@ -290,14 +291,14 @@
CP(*in, *out, f_flags);
CP(*in, *out, f_syncwrites);
CP(*in, *out, f_asyncwrites);
- bcopy(in->f_fstypename,
- out->f_fstypename, MFSNAMELEN);
- bcopy(in->f_mntonname,
- out->f_mntonname, MNAMELEN);
+ bcopy(in->f_fstypename, out->f_fstypename,
+ MIN(MFSNAMELEN, FREEBSD32_MFSNAMELEN - 1));
+ bcopy(in->f_mntonname, out->f_mntonname,
+ MIN(MNAMELEN, FREEBSD32_MNAMELEN - 1));
CP(*in, *out, f_syncreads);
CP(*in, *out, f_asyncreads);
- bcopy(in->f_mntfromname,
- out->f_mntfromname, MNAMELEN);
+ bcopy(in->f_mntfromname, out->f_mntfromname,
+ MIN(MNAMELEN, FREEBSD32_MNAMELEN - 1));
}
int
---
* sys/ia64/ia32/ia32.h: It seems to me that statfs32 has similar problems
as freebsd32.h - however in this case real and bigger, because statfs32
is now a combination of old and new statfs: old 32bit fields with new
string lengths, so sizeof(statfs32) is changed from 256 to 272. Is this
really correct? If I understand it correctly, it breaks binary
compatibility for old ia32 binaries. I think that MFSNAMELEN/MNAMELEN
should be renamed to OMFSNAMELEN/OMNAMELEN, or ia32.h should define own
IA32_MFSNAMELEN/IA32_MNAMELEN, similarly to freebsd32.h - which is more
secure with respect to further updates in the future.
* sys/ia64/ia32/ia32_misc.c: If ia32.h is changed/fixed, copy_statfs()
has the same problems, as is in freebsd32_misc.c.
* sys/alpha/osf1/osf1_mount.c: And just small trash at the end, because
it is in #ifdef notanymore ... #endif ;o) (however it means, that osf1
statfs calls are completely broken?), but why bsd2osf_statfs() has
3 x max()? What about following patch?
--- sys/alpha/osf1/osf1_mount.c.origTue Nov 18 17:40:08 2003
+++ sys/alpha/osf1/osf1_mount.c Tue Nov 18 17:40:52 2003
@@ -88,7 +88,7 @@
{
#ifdef notanymore
-bzero(osfs, sizeof (struct osf1_statfs));
+ bzero(osfs, sizeof (struct osf1_statfs));
if (!strncmp(fsnames[MOUNT_UFS], bsfs->f_fstypename, MFSNAMELEN))
osfs->f_type = OSF1_MOUNT_UFS;
else if (!strncmp(fsnames[MOUNT_NFS], bsfs->f_fstyp
Re: HEADS-UP new statfs structure
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 good though. > > I have a feeling OpenOffice (1.0) is also broken by this. I'm sure we could go on like this for ages, but the lesson to be learned is that you should rebuild all your installed applications (e.g. portupgrade -fa) to be sure there are no hidden surprises waiting to bite you weeks or months down the line. Kris pgp0.pgp Description: PGP signature
Re: HEADS-UP new statfs structure
-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 have a feeling OpenOffice (1.0) is also broken by this. #0 0x285eb243 in osl_psz_getVolumeInformation () from /usr/local/OpenOffice.org1.0/program/libsal.so.3 Looks like something to do with disks to me. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/uhQ4LqgJ90OcaiARAsYuAKDgHgVsJYlXTmT8MOvvI+AQsJPbLwCbBo8C RmBzxNU60/6WfQjLcyjAC64= =yO/7 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure condidered harmful
: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 putting structure recopies into the critical path of a
:syscall.
:
:--
:Doug White| FreeBSD: The Power to Serve
Umm, no. I'm not sure why you are taking such a negative view of
things, the actual implementation is whole lot simpler then you seem to
believe.
What we will be doing is adding new system calls to replace *stat() and
*statfs(). They will for obvious reasons not be named the same, nor
would the old system calls be removed.
The new system calls will generate a capability list into a buffer
supplied by userland, which is really no different from the copyout that
the old system calls already do.
The only difference is that the userland libc function that takes over
the *stat() and *statfs() functionality using the new system calls
(obsoleting the original system calls) will have to have to loop
through the capability list and populate the user-supplied statfs or
stat structure from it. Since the returned capability list is simply
a stack based buffer there won't be any cache contention and the data
will already be in the L1 cache. My guess is that it would add
perhaps 150ns to these system calls compared to the 3-5uS they already
take for the non-I/O case.
The capability list would be 'chunky'. e.g. one capability record
would represent all three timespecs for example, another record
would represent uid, and gid. Another record record represent file
size and block count, and so forth.
They key point is that the individual capability elements would not
change, ever. Instead if a change is needed a new capability element
would be added and an argument to the new syscalls will let the system
know whether it needs to generate the older elements that the newer ones
replace. Userland will ignore capabilities it does not understand.
The result is full forwards and backwards compatibility, forever.
I do not believe there is any performance impact at all, especially
if stat has to go do I/O. If you care about performance then I
recommend that you fix the syscall path in 5.x instead of worrying
yourself over stat(). If a particular program really needs to save the
150ns, say 'find', then it can call the new system call directly. But
I really doubt anyone would notice 'find' running any slower.
I certainly care a great deal about performance in DragonFly and I am
not worried about the capability idea's impact *AT* *ALL*.
The userland implementation would be something like this:
int
stat(const char *file, struct stat *st)
{
char tmpbuf[SMALLBUF]; /* stat info is expected to fit */
char *buf = tmpbuf;
int off;
int len;
struct stat_cap_header *cap;
/*
* Run the system call. Try a small buffer first (designed to
* succeed for the current version of the OS). If it fails then
* allocate a larger buffer (compatibility with future OSs that might
* provide more information).
*/
if ((len = stat_cap(file, buf, STAT_CAP_STDFIELDS)) < 0) {
if (errno != E2BIG)
return(-1);
buf = malloc(((struct stat_cap_header *)buf)->c_len);
if ((len = stat_cap(file, buf, STAT_CAP_STDFIELDS)) < 0) {
free(buf);
return(-1);
}
}
/*
* Populate the stat structure (this could be common code for all
* stat*() calls).
*/
off = 0;
while (off < len) {
cap = (struct stat_cap_header *)(buf + off);
switch(cap->c_type) {
case STAT_TIMESPEC1:
st->st_atimespec = cap->c_timespec1.atimespec;
st->st_mtimespec = cap->c_timespec1.mtimespec;
st->st_ctimespec = cap->c_timespec1.ctimespec;
break;
case STAT_UIDGID1:
st->st_uid = cap->c_uidgid1.uid;
st->st_gid = cap->c_uidgid1.gid;
break;
...
}
off += cap->c_len;
}
if (buf != tmpbuf)
free(buf);
return(0);
}
-Matt
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure condidered harmful
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 it always has. 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 putting structure recopies into the critical path of a syscall. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 keep missing that mark with the 6.x-series, then we should plan to do something to make life a little > less painful. The API and ABI are frozen when we make 5.x-STABLE and branch 6.x. Until then it's open to change. This was decided up front. Hmm, Yes it was. I was mixing up the time of X.0-RELEASE and making the branch for -current. Good point. Please note that I'm not unhappy with any of these changes. I think they're all very good to get in. But we do have hundreds of developers trying to track -current, and I think we'd get some productivity boost whenever we can make these changes a little smoother. As I mentioned earlier, it's only going to get worse as we have more developers trying to contribute. Developers that we *do* want to be tracking -current... And to mention just one change that I'm particularly happy with, the change so a single kernel works on both SMP and single-processor systems has already saved me some grief. My hardware problems were (temporarily) solved by replacing my dual-CPU board with a single-CPU one. I'd be in even more pain today if it wasn't for that change! I still haven't figured out what I'll do with the 4.9-stable system on this machine... [disclaimer: today has been a long day for me, all spent rebuilding freebsd systems from this hardware headache. I just now finished successfully upgrading the last 5.x system I have (it just booted up as I am typing this). So don't mind me too much...] -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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, 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 to see a.out libs from ELF ones. > : (yes I still have some a.out binaries) > > And there is no such thing as a minor version number on elf anyway. There isn't even a major version number. There's only strcmp(). -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 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 that we : > 1. keep the major number to allow concurrent development of different : >(major) library versions, and : > 2. replace the date with a convenient sequence number, which we can : >call the minor version number, and : > 3. Do not reset the version number when we release. : > : > E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2... : : I don't care so much about naming conventions. It would just be : nice to be able to bump the version in development as often as : you like without usurping release version ids (major or minor). : You can still use minor numbers while still not throwing some away: : : 6.0 Branch - libc.so.6.1000 : libc bump - libc.so.6.1001 : libc bump - libc.so.6.1002 : 6.0-Release - libc.so.6.0 : libc bump - libc.so.6.1003 : 6.1-Release - libc.so.6.1 : ... Please no. ELF libraries have no minor numbers and a scheme like this would likely cause no end of problems. For FreeBSD 6.x we should keep the same API and actively pursue people that want to break it with large pointy sticks. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 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 to see a.out libs from ELF ones. : >(yes I still have some a.out binaries) : : Maybe: : libc.so.6.e0, libc.so.6.e1, and (first release) libc.so.6.e2... : : I have no idea what would be best to do, but I do think we : (developers and users alike) would be much better off if : we had some way to handle all these changes which come in. : : 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 keep missing that mark with the 6.x-series, : then we should plan to do something to make life a little : less painful. Right now it's getting more painful, if for : no other reason than we have more developers, and thus more : major-changes in the pipeline. Actually, 5.x is an anomaly. We'd planned on freezing the 5.0 ABI at 5.0, but we missed that mark and are waiting for 5.3 to freeze the ABI, treaing 5.0, 5.1 and 5.2 as if they were pre-releases. For 6.0 we'll be back to having libc.so.6. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2... : : Please no -- it wouldn't be easy to see a.out libs from ELF ones. : (yes I still have some a.out binaries) And there is no such thing as a minor version number on elf anyway. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 -current > > > folk. > > > > This is a great idea! > > Provided that we > 1. keep the major number to allow concurrent development of different >(major) library versions, and > 2. replace the date with a convenient sequence number, which we can >call the minor version number, and > 3. Do not reset the version number when we release. > > E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2... I don't care so much about naming conventions. It would just be nice to be able to bump the version in development as often as you like without usurping release version ids (major or minor). You can still use minor numbers while still not throwing some away: 6.0 Branch - libc.so.6.1000 libc bump - libc.so.6.1001 libc bump - libc.so.6.1002 6.0-Release - libc.so.6.0 libc bump - libc.so.6.1003 6.1-Release - libc.so.6.1 ... -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 policy of not trying to break compatibility in -STABLE, although that isn't strictly adhered to in practise. Kris pgp0.pgp Description: PGP signature
Re: HEADS-UP new statfs structure
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 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 to see a.out libs from ELF ones. > >(yes I still have some a.out binaries) > > Maybe: > libc.so.6.e0, libc.so.6.e1, and (first release) libc.so.6.e2... > > I have no idea what would be best to do, but I do think we > (developers and users alike) would be much better off if > we had some way to handle all these changes which come in. > > 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 keep missing that mark with the 6.x-series, > then we should plan to do something to make life a little > less painful. Right now it's getting more painful, if for > no other reason than we have more developers, and thus more > major-changes in the pipeline. The API and ABI are frozen when we make 5.x-STABLE and branch 6.x. Until then it's open to change. This was decided up front. Cheers, Jeff > > -- > Garance Alistair Drosehn= [EMAIL PROTECTED] > Senior Systems Programmer or [EMAIL PROTECTED] > Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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) libc.so.6.2... Please no -- it wouldn't be easy to see a.out libs from ELF ones. (yes I still have some a.out binaries) Maybe: libc.so.6.e0, libc.so.6.e1, and (first release) libc.so.6.e2... I have no idea what would be best to do, but I do think we (developers and users alike) would be much better off if we had some way to handle all these changes which come in. 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 keep missing that mark with the 6.x-series, then we should plan to do something to make life a little less painful. Right now it's getting more painful, if for no other reason than we have more developers, and thus more major-changes in the pipeline. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 to see a.out libs from ELF ones. (yes I still have some a.out binaries) -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure condidered harmful
:> 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 program doesn't know the difference, it uses fstat() and statfs() just like it always has. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure condidered harmful
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 understands into the > structure. That way you don't have to worry about forwards and > backwards kernel compatibility. > > This is what I plan to do with DragonFly for *stat(), *statfs*(), > various sysctls that return structures, and so forth. Wherever it makes > sense to do it. How do you propose to achieve POSIX compliance? At the library level? Or "not at all"? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 that we 1. keep the major number to allow concurrent development of different (major) library versions, and 2. replace the date with a convenient sequence number, which we can call the minor version number, and 3. Do not reset the version number when we release. E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 their smaller > struct statfs is located, may stomp on memory they're using for something > else (like critical data structures). This means that any application > using statfs() and linked against libc.so.5 may start having problems. > Not only that, but as you begin to compile new programs, they start > expecting the new statfs() API, so if you keep the old libc, they'll start > expecting to see extended struct statfs information in a structure that's > too small. This is almost certainly a less harmful failure mode than the > former. However, it turns out statfs() is used in a fair number of > applications (and libraries)... I recently ran into a similar need to break the API without breaking the ABI. The easiest way to do this is to add a new system call, with a different name, and scope the changeover to compile time. At some later point, when you bump the libc version, you can change the name to the new name, and deprecate the old. For the "statfs" case, here's the example: % nm /usr/lib/libc.a | grep "T _statfs" 0008 T _statfs 0008 T _statfs_new % grep statfs /usr/include/sys/mount.h #define statfs statfs_new int statfs(const char *, struct statfs *); Viola! Recompile, get the new, don't recompile, get the old. The only place this breaks is sucky programs that define the structure without including the header file to get the prototype and #define in scope as well. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 that's a good idea. I've also got changes in > mind that require a libc version bump, but they aren't ready > now. I was saving them for 6.0. Other folks may also have > similar changes in mind. Do we really want to have yet another > version bump? No, we want a minor version bump to add a new interface, but since we got rid of minor version numbers on libraries, this is no longer possible. 8-). > 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! -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure condidered harmful
: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 this fundamental. : :Effectively, this will destroy binary backward compatability for :everything in the world. : :-- Terry :___ :[EMAIL PROTECTED] mailing list 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 understands into the structure. That way you don't have to worry about forwards and backwards kernel compatibility. This is what I plan to do with DragonFly for *stat(), *statfs*(), various sysctls that return structures, and so forth. Wherever it makes sense to do it. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure condidered harmful
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 4049 (smtpd), uid 1003: exited on signal 11 > > 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. 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 this fundamental. Effectively, this will destroy binary backward compatability for everything in the world. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 problems at all. I installed the new kernel and world, rebuilt x11/nvidia-driver and X11 hung before it had even switched to graphical mode. After a minute the system rebooted, and I got the same behavoir a few days ago BEFORE rebuilding the system, so i don't think it is due to the statfs change. The driver stopped working around the time the XFree86 ports were changed, I think that these are more likely the cause. But, all my apps are up to date so the Nvidia driver is still working. I haven't update -CURRENT yet, I am waiting for Gnome 2.5 to be out then I will update -CURRENT and stuff. # pkg_info | grep XFree86 XFree86-4.3.0,1 X11/XFree86 core distribution (complete, using mini/meta-po XFree86-FontServer-4.3.0_2 XFree86-4 font server XFree86-Server-4.3.0_12 XFree86-4 X server and related programs XFree86-clients-4.3.0_5 XFree86-4 client programs and related files XFree86-documents-4.3.0 XFree86-4 documentation XFree86-font100dpi-4.3.0 XFree86-4 bitmap 100 dpi fonts XFree86-font75dpi-4.3.0 XFree86-4 bitmap 75 dpi fonts XFree86-fontCyrillic-4.3.0 XFree86-4 Cyrillic fonts XFree86-fontDefaultBitmaps-4.3.0 XFree86-4 default bitmap fonts XFree86-fontEncodings-4.3.0 XFree86-4 font encoding files XFree86-fontScalable-4.3.0 XFree86-4 scalable fonts XFree86-libraries-4.3.0_6 XFree86-4 libraries and headers dri-4.3.0,1 OpenGL hardware acceleration drivers for XFree86 imake-4.3.0_1 Imake and other utilities from XFree86 wrapper-1.0_3 Wrapper for XFree86-4 server # pkg_info | grep nvidia nvidia-driver-1.0.4365 [...with non-offical patch...] Cheers, Mezz The odd thing is that this seems to be system dependent, on my P4 system at home the driver still works fine, on my Athlon system at work I have the same issues you describe here... I haven't done anything to debug or fix this because I need the failing system to work with rather then to play around with ;) But if anyone wants to look into that I'll provide every information needed. Greets, Sascha -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 if they are re-compiled, won't they be re-compiled with the newer struct statfs? (and thus be the correct size) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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/nvidia-driver and X11 hung before it had even > switched to graphical mode. After a minute the system rebooted, and I got the same behavoir a few days ago BEFORE rebuilding the system, so i don't think it is due to the statfs change. The driver stopped working around the time the XFree86 ports were changed, I think that these are more likely the cause. The odd thing is that this seems to be system dependent, on my P4 system at home the driver still works fine, on my Athlon system at work I have the same issues you describe here... I haven't done anything to debug or fix this because I need the failing system to work with rather then to play around with ;) But if anyone wants to look into that I'll provide every information needed. Greets, Sascha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 it). I'm a bit puzzled, > anyone else seeing this or is it a pilot error? 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 their smaller struct statfs is located, may stomp on memory they're using for something else (like critical data structures). This means that any application using statfs() and linked against libc.so.5 may start having problems. Not only that, but as you begin to compile new programs, they start expecting the new statfs() API, so if you keep the old libc, they'll start expecting to see extended struct statfs information in a structure that's too small. This is almost certainly a less harmful failure mode than the former. However, it turns out statfs() is used in a fair number of applications (and libraries)... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 seeing this or is it a pilot error? -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 released :-) > > > > 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 that's a good idea. I've also got changes in > mind that require a libc version bump, but they aren't ready > now. I was saving them for 6.0. Other folks may also have > similar changes in mind. Do we really want to have yet another > version bump? It costs ~1MB in disk space for each libc bump, yes that's expensive. But so is having many random, non-system applications bomb after you upgrade. Shooting all early adopters in the head is really bad for PR. I think that 1MB of disk space is worth it. > For 6.0, can we start off libc at libc.so.MMDD and move it Yes! Yes! Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 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 that's a good idea. I've also got changes in mind that require a libc version bump, but they aren't ready now. I was saving them for 6.0. Other folks may also have similar changes in mind. Do we really want to have yet another version bump? 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. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 time it received a mail until I recompiled it: pid 4049 (smtpd), uid 1003: exited on signal 11 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. 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/nvidia-driver and X11 hung before it had even switched to graphical mode. After a minute the system rebooted, and unfortunately a couple of lost+found directories were populated by fsck - I must remember to turn off the ata write cache next time! I've now rebuilt *all* of the ports in the hope that it would solve it, but it still crashes. -- Bruce Cran I am using the nvidia driver fine with the latest current: nvidia0: mem 0xfc20-0xfc27,0xf800-0xfbff,0xfd00-0xfdff irq 5 at device 0.0 on pci1 FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Nov 13 18:34:54 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 The only thing I've found a problem with so far is postfix as I've mentioned. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 received a mail until I recompiled it: > > pid 4049 (smtpd), uid 1003: exited on signal 11 > > 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. > 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/nvidia-driver and X11 hung before it had even switched to graphical mode. After a minute the system rebooted, and unfortunately a couple of lost+found directories were populated by fsck - I must remember to turn off the ata write cache next time! I've now rebuilt *all* of the ports in the hope that it would solve it, but it still crashes. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 continue to work? Having things like postfix and gnome dumping core seems excessivly bumpy. Upgrading all ports is a pain. Yes, I realize that people upgrading from 4.x won't see this, but people upgrading from 5.1-R will. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
> 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: exited on signal 11 > > 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. > > Matt. This is why we make this change now so that it will be in place for the masses when 5.2 is released :-) Kirk McKusick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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: exited on signal 11 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. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
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 old statfs > structure, but an old kernel will not know about the new system > calls that support the new statfs structure. Running an old kernel > after a `make world' will cause programs such as `df' that do a > statfs system call to fail with a bad system call. shouldn't in addition to this mail requested by Scott UPDATING also be updated ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS-UP new statfs structure
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 know about the new system calls that support the new statfs structure. Running an old kernel after a `make world' will cause programs such as `df' that do a statfs system call to fail with a bad system call. Kirk McKusick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
