Re: GEOM code ready for testing

[Rasmus Skaarup]

On Tue, 12 Mar 2002, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Carl Makin writes:

 On Mon, 2002-03-11 at 06:34, Poul-Henning Kamp wrote:
 
  The GEOM code is now ready for early testing:
 
 Would GEOM support accessing a device via multiple paths? (ie could we
 write a method that would do that?)

 Yes, that would be possible.

Have you given any thought to how that might be implemented? If somekind
of ID is required to identify the same disk via multiple paths, in which
part of GEOM will this be implemented?

I can't figure out from your documentation whether you have somekind of
Master GEOM instance that initiates the device recognition, or otherwise
how is this initiated?



Best regards,
Rasmus Skaarup


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GEOM code ready for testing

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Rasmus Skaarup writes:

On Tue, 12 Mar 2002, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Carl Makin writes:

 On Mon, 2002-03-11 at 06:34, Poul-Henning Kamp wrote:
 
  The GEOM code is now ready for early testing:
 
 Would GEOM support accessing a device via multiple paths? (ie could we
 write a method that would do that?)

 Yes, that would be possible.

Have you given any thought to how that might be implemented? If somekind
of ID is required to identify the same disk via multiple paths, in which
part of GEOM will this be implemented?

I can't figure out from your documentation whether you have somekind of
Master GEOM instance that initiates the device recognition, or otherwise
how is this initiated?

Basically when a new g_provider is created it is offered to each method
in turn and if that method likes it, it can stick g_geom on top of it.

How you would recognize the same disk on thre different paths is a good
question.  We could implement (if we don't already have it) an 
ioctl/BIO_GETATTR which returns the serial number(s) of the diskdevice
and you could query that.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GEOM code ready for testing

[Rasmus Skaarup]

On Tue, 12 Mar 2002, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Rasmus Skaarup writes:
 
 On Tue, 12 Mar 2002, Poul-Henning Kamp wrote:
 
  In message [EMAIL PROTECTED], Carl Makin writes:
 
  Would GEOM support accessing a device via multiple paths? (ie could we
  write a method that would do that?)
 
  Yes, that would be possible.
 
 Have you given any thought to how that might be implemented? If somekind
 of ID is required to identify the same disk via multiple paths, in which
 part of GEOM will this be implemented?
 

 Basically when a new g_provider is created it is offered to each method
 in turn and if that method likes it, it can stick g_geom on top of it.

Ahh.. But do you rule out the possibility that two methods could apply to
a g_provider? Or is this even a problem?

 How you would recognize the same disk on thre different paths is a good
 question.  We could implement (if we don't already have it) an
 ioctl/BIO_GETATTR which returns the serial number(s) of the diskdevice
 and you could query that.

Hmm, but I'm not sure all kinds of storage devices have serialnumbers that
could be fetched (tape devices for instance?) and can we rely on the
hardware manufacturers to provide unique serialnumbers?


Best regards,
Rasmus Skaarup




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GEOM code ready for testing

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Rasmus Skaarup writes:

 Basically when a new g_provider is created it is offered to each method
 in turn and if that method likes it, it can stick g_geom on top of it.

Ahh.. But do you rule out the possibility that two methods could apply to
a g_provider? Or is this even a problem?

the relationships in geom are:


g_method   --- 1 : N --- g_geom
Each method can have multiple instances.

g_geom --- 1 : N --- g_consumer
An instance can attach to multiple providers
(striping, mirroring, raid5)

g_geom --- 1 : N --- g_provider
An instance can split into more providers.
(BSD/disklabel, MBR)

g_provider --- 1 : N --- g_consumer
Multiple consumers can attach to one provider.

 How you would recognize the same disk on thre different paths is a good
 question.  We could implement (if we don't already have it) an
 ioctl/BIO_GETATTR which returns the serial number(s) of the diskdevice
 and you could query that.

Hmm, but I'm not sure all kinds of storage devices have serialnumbers that
could be fetched (tape devices for instance?) and can we rely on the
hardware manufacturers to provide unique serialnumbers?

Well, the recognition/configuration issue is not one GEOM magically can
solve for you, but GEOM promises that if you can recognize it and
configure it, GEOM will not get in your way for doing what you want.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

list

[Ramses van Pinxteren]

list

Ing. Ramses H. Th. van Pinxteren 
CMG Finance BV. 
afdeling AV-Advanced Technologies 1
Laan van Kronenburg 14
postbus 133
1180 AC Amstelveen
tel: +31 (0)20 503 3000
fax: +31 (0)20 503 3011
email: [EMAIL PROTECTED] 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GEOM code ready for testing

[Rasmus Skaarup]

On Tue, 12 Mar 2002, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Rasmus Skaarup writes:

  How you would recognize the same disk on thre different paths is a good
  question.  We could implement (if we don't already have it) an
  ioctl/BIO_GETATTR which returns the serial number(s) of the diskdevice
  and you could query that.
 
 Hmm, but I'm not sure all kinds of storage devices have serialnumbers that
 could be fetched (tape devices for instance?) and can we rely on the
 hardware manufacturers to provide unique serialnumbers?

 Well, the recognition/configuration issue is not one GEOM magically can
 solve for you, but GEOM promises that if you can recognize it and
 configure it, GEOM will not get in your way for doing what you want.

But what if the name of the device somehow depended on the ID on the
device? So you could recognize the same disk on multiple hosts, and having
the same name for the device on each host.

But this should maybe be left up to the method to assign?


Best regards,
Rasmus Skaarup


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GEOM code ready for testing

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Rasmus Skaarup writes:

 Well, the recognition/configuration issue is not one GEOM magically can
 solve for you, but GEOM promises that if you can recognize it and
 configure it, GEOM will not get in your way for doing what you want.

But what if the name of the device somehow depended on the ID on the
device? So you could recognize the same disk on multiple hosts, and having
the same name for the device on each host.

But this should maybe be left up to the method to assign?

The methods decide the names of their g_geom and g_providers.

If you look in the BSD and MBR modules, you can see how they simply
tack a letter or s%d onto the name from below.  There is nothing
to prevent you from creating an entirely new name if you want to.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

early vfs_mountroot commit 20020308

[dave adkins]

Hi,

Since the commit of the early vfs_mountroot on Mar 8, I have been unable
to boot current. After reverting to the previous versions of init_main.c
(1.187) vfs_conf.c (1.65) and sys/mount.h (1.117) current boots fine.

My kernel configuration is:

#
#
#

machine i386
#cpuI486_CPU
#cpuI586_CPU
cpu I686_CPU
ident   SMP
maxusers0

#To statically compile in device wiring instead of /boot/device.hints
#hints  GENERIC.hints #Default places to look for devices.


#makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols

options INET#InterNETworking
options INET6   #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options SOFTUPDATES #Enable FFS soft updates support
options UFS_DIRHASH #Improve performance on big directories
options MD_ROOT #MD is a potential root device
options NFSCLIENT   #Network Filesystem Client
options NFSSERVER   #Network Filesystem Server
options NFS_ROOT#NFS usable as root device, requires NFSCLIENT
options MSDOSFS #MSDOS Filesystem
options CD9660  #ISO 9660 Filesystem
options PROCFS  #Process filesystem (requires PSEUDOFS)
options PSEUDOFS#Pseudo-filesystem framework
options COMPAT_43   #Compatible with BSD 4.3 [KEEP THIS!]
options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI
options UCONSOLE#Allow users to grab the console
#optionsUSERCONFIG  #boot -c editor
#optionsVISUAL_USERCONFIG   #visual boot -c editor
options KTRACE  #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
options P1003_1B#Posix P1003_1B real-time extensions
options _KPOSIX_PRIORITY_SCHEDULING
options KBD_INSTALL_CDEV# install a CDEV entry in /dev

options EXT2FS

# Debugging for use in -current
options DDB #Enable the kernel debugger

options INVARIANTS  #Enable calls of extra sanity checking
options INVARIANT_SUPPORT   #Extra sanity checks of internal structures, 
required by INVARIANTS
options WITNESS #Enable mutex checks to detects deadlocks and 
cycles

options MAXMEM=(512*1024)

# To make an SMP kernel, the next two are needed

options SMP # Symmetric MultiProcessor Kernel
options APIC_IO # Symmetric (APIC) I/O


device  isa
device  eisa
device  pci
#optionsPCI_ENABLE_IO_MODES # Enable pci resources left off by a lazy 
BIOS

# Floppy drives
device  fdc

# ATA and ATAPI devices
device  ata
device  atadisk # ATA disk drives
device  atapicd # ATAPI CDROM drives
device  atapifd # ATAPI floppy drives
device  atapist # ATAPI tape drives
options ATA_STATIC_ID   #Static device numbering

# SCSI Controllers
#device ahb # EISA AHA1742 family
device  ahc # AHA2940 and onboard AIC7xxx devices
#device amd # AMD 53C974 (Tekram DC-390(T))
#device isp # Qlogic family
#device ncr # NCR/Symbios Logic
#device sym # NCR/Symbios Logic (newer chipsets + those of `ncr')

#device adv # Advansys SCSI adapters
#device adw # Advansys wide SCSI adapters
#device aha # Adaptec 154x SCSI adapters
#device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60.
#device bt  # Buslogic/Mylex MultiMaster SCSI adapters

#device ncv # NCR 53C500
#device nsp # Workbit Ninja SCSI-3
#device stg # TMC 18C30/18C50

# RAID controllers interfaced to the SCSI subsystem
#device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID
#device dpt # DPT Smartcache III, IV - See NOTES for options!
#device mly # Mylex AcceleRAID/eXtremeRAID

# SCSI peripherals
device  scbus   # SCSI bus (required)
device  ch  # SCSI media changers
device  da  # Direct Access (disks)
device  sa  # Sequential Access (tape etc)
device  cd  # CD
device  pass# Passthrough device (direct SCSI 

Re: GEOM code ready for testing

[Kenneth D. Merry]

On Tue, Mar 12, 2002 at 11:58:02 +0100, Rasmus Skaarup wrote:
 On Tue, 12 Mar 2002, Poul-Henning Kamp wrote:
  In message [EMAIL PROTECTED], Carl Makin writes:
 
  On Mon, 2002-03-11 at 06:34, Poul-Henning Kamp wrote:
  
   The GEOM code is now ready for early testing:
  
  Would GEOM support accessing a device via multiple paths? (ie could we
  write a method that would do that?)
 
  Yes, that would be possible.
 
 Have you given any thought to how that might be implemented? If somekind
 of ID is required to identify the same disk via multiple paths, in which
 part of GEOM will this be implemented?
 
 I can't figure out from your documentation whether you have somekind of
 Master GEOM instance that initiates the device recognition, or otherwise
 how is this initiated?

FWIW, Justin and I have been thinking about (for years, actually) doing
multipath support inside CAM.

We would figure out that a device is unique via a serial number or WWN.
There would probably also be a manual identification method that would
allow the user to specify that a given device can be accessed via multiple
routes.

That would be useful for devices without a unique serial number.

For disks, probably the best thing to do is to have some sort of label on
the disk and use that to determine which disks are the same.

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GEOM code ready for testing

[Justin T. Gibbs]

FWIW, Justin and I have been thinking about (for years, actually) doing
multipath support inside CAM.

Actually, the multipathing support would be in new-bus and CAM would be
one newbus client able to detect redundant paths and register them
accordingly.

The main thing to remember is that there are lots of device types that
want to export the concept of multiple paths.  CAM and GEOM may implement
different policies with those paths or the devices in question may not
even be of interest to those two subsystems.  This is why the support
should be generic enough to be used by CAM, GEOM, and all of the uses
to follow.  With newbus, this becomes pretty trivial.  Each device
node has a method for enumerating its paths.  CAM or GEOM or X new
cool thing, can then devise their own policy to handle this information.

--
Justin

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GEOM code ready for testing

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Kenneth D. Merry writes:

  Would GEOM support accessing a device via multiple paths? (ie could we
  write a method that would do that?)
 
  Yes, that would be possible.

FWIW, Justin and I have been thinking about (for years, actually) doing
multipath support inside CAM.

You know, thinking about it, I actually think it is a stronger model
to do it in GEOM, since that will be able to cover more cases than
CAM will be able to.

That said, since I am not on the hook to implement either so I will
not impose my opinion one one way or the other :-)

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

4.5-5.0 kldxref:No such file or directory

[huntting]

make DESTDIR=/5.0 world kernel encountered the following problem:

[...]
--
 Kernel build for GENERIC completed on Tue Mar 12 20:26:10 GMT 2002
--
[...]
--
 Kernel build for GENERIC completed on Tue Mar 12 20:26:10 GMT 2002
--
cd /usr/obj/5.0/usr/src/sys/GENERIC;  MAKEOBJDIRPREFIX=/usr/obj  
MACHINE_ARCH=i3
[...]
=== xe
install -c -o root -g wheel -m 555   if_xe.ko /5.0/boot/kernel/
kldxref /5.0/boot/kernel
kldxref:No such file or directory
*** Error code 1 (ignored)

Since there is no kldxref in 4.5, this should probably included in
the bootstrap process somehow.

As an asside, I've noticed in the past when upgrading from 4.0 to
5.0, I've had to forcebly reinstall the loader.  I dont know why,
but the loader shiped with (at least) 4.4 doesnt seem to like
loading 5.0 kernel bits.


brad

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Adding realloc()

[Alfred Perlstein]

* Archie Cobbs [EMAIL PROTECTED] [020311 22:00] wrote:
 Hi,
 
 I've had the need for a realloc() in the kernel several times
 before and am having it once again. Finally figured it's time to
 do something about it.
 
 Does anyone have problems with the attached patch? This patch adds
 realloc() and also fixes the semantics of free() to be consistent
 with userland, in that free(NULL) is legal and does nothing. This
 will make it possible to simplify some netgraph code and probably
 other stuff too. Reviews appreciated as well.

Where is the update to malloc(9)?  What about reallocf?

-Alfred

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Adding realloc()

[Archie Cobbs]

Alfred Perlstein writes:
  I've had the need for a realloc() in the kernel several times
  before and am having it once again. Finally figured it's time to
  do something about it.
 
 Where is the update to malloc(9)?  What about reallocf?

Good points, thanks.. try this one instead.

-Archie

__
Archie Cobbs * Packet Design * http://www.packetdesign.com


Index: sys/kern/kern_malloc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.93
diff -u -r1.93 kern_malloc.c
--- kern_malloc.c	12 Sep 2001 08:37:44 -	1.93
+++ kern_malloc.c	12 Mar 2002 22:34:35 -
 -57,6 +57,16 
 #include machine/cpu.h
 #endif
 
+/*
+ * When realloc() is called, if the new size is sufficiently smaller than
+ * the old size, realloc() will allocate a new, smaller block to avoid
+ * wasting memory. 'Sufficiently smaller' is defined as: newsize =
+ * oldsize / 2^n, where REALLOC_FRACTION defines the value of 'n'.
+ */
+#ifndef REALLOC_FRACTION
+#define	REALLOC_FRACTION	1	/* new block if = half the size */
+#endif
+
 MALLOC_DEFINE(M_CACHE, cache, Various Dynamically allocated caches);
 MALLOC_DEFINE(M_DEVBUF, devbuf, device driver memory);
 MALLOC_DEFINE(M_TEMP, temp, misc temporary data buffers);
 -294,6 +304,10 
 #endif
 	register struct malloc_type *ksp = type;
 
+	/* free(NULL, ...) does nothing */
+	if (addr == NULL)
+		return;
+
 	KASSERT(kmembase = (char *)addr  (char *)addr  kmemlimit,
 	(free: address %p out of range, (void *)addr));
 	kup = btokup(addr);
 -397,6 +411,66 
 #endif
 	splx(s);
 	mtx_unlock(malloc_mtx);
+}
+
+/*
+ *	realloc: change the size of a memory block
+ */
+void *
+realloc(addr, size, type, flags)
+	void *addr;
+	unsigned long size;
+	struct malloc_type *type;
+	int flags;
+{
+	struct kmemusage *kup;
+	unsigned long alloc;
+	void *newaddr;
+
+	/* realloc(NULL, ...) is equivalent to malloc(...) */
+	if (addr == NULL)
+		return (malloc(size, type, flags));
+
+	/* Sanity check */
+	KASSERT(kmembase = (char *)addr  (char *)addr  kmemlimit,
+	(realloc: address %p out of range, (void *)addr));
+
+	/* Get the size of the original block */
+	kup = btokup(addr);
+	alloc = 1  kup-ku_indx;
+	if (alloc  MAXALLOCSAVE)
+		alloc = kup-ku_pagecnt  PAGE_SHIFT;
+
+	/* Reuse the original block if appropriate */
+	if (size = alloc
+	 (size  (alloc  REALLOC_FRACTION) || alloc == MINALLOCSIZE))
+		return (addr);
+
+	/* Allocate a new, bigger (or smaller) block */
+	if ((newaddr = malloc(size, type, flags)) == NULL)
+		return (NULL);
+
+	/* Copy over original contents */
+	bcopy(addr, newaddr, min(size, alloc));
+	free(addr, type);
+	return (newaddr);
+}
+
+/*
+ *	reallocf: same as realloc() but free memory on failure.
+ */
+void *
+reallocf(addr, size, type, flags)
+	void *addr;
+	unsigned long size;
+	struct malloc_type *type;
+	int flags;
+{
+	void *mem;
+
+	if ((mem = realloc(addr, size, type, flags)) == NULL)
+		free(addr, type);
+	return (mem);
 }
 
 /*
Index: sys/sys/malloc.h
===
RCS file: /home/ncvs/src/sys/sys/malloc.h,v
retrieving revision 1.54
diff -u -r1.54 malloc.h
--- malloc.h	10 Aug 2001 06:37:04 -	1.54
+++ malloc.h	12 Mar 2002 22:34:46 -
 -173,6 +173,10 
 void	*malloc __P((unsigned long size, struct malloc_type *type, int flags));
 void	malloc_init __P((void *));
 void	malloc_uninit __P((void *));
+void	*realloc __P((void *addr, unsigned long size,
+		  struct malloc_type *type, int flags));
+void	*reallocf __P((void *addr, unsigned long size,
+		  struct malloc_type *type, int flags));
 #endif /* _KERNEL */
 
 #endif /* !_SYS_MALLOC_H_ */
Index: share/man/man9/malloc.9
===
RCS file: /home/ncvs/src/share/man/man9/malloc.9,v
retrieving revision 1.21
diff -u -r1.21 malloc.9
--- malloc.9	1 Oct 2001 16:09:25 -	1.21
+++ malloc.9	12 Mar 2002 22:34:57 -
 -54,18 +54,63 
 .Ft void
 .Fn free void *addr struct malloc_type *type
 .Fn FREE void *addr struct malloc_type *type
+.Ft void *
+.Fn realloc void *addr unsigned long size struct malloc_type *type int flags
+.Ft void *
+.Fn reallocf void *addr unsigned long size struct malloc_type *type int flags
 .Sh DESCRIPTION
 The
 .Fn malloc
 function allocates uninitialized memory in kernel address space for an
 object whose size is specified by
 .Fa size .
+.Pp
 .Fn free
 releases memory at address
 .Fa addr
 that was previously allocated by
 .Fn malloc
-for re-use.  The memory is not zeroed.
+for re-use.
+The memory is not zeroed.
+If
+.Fa addr
+is
+.Dv NULL ,
+then
+.Fn free
+does nothing.
+.Pp
+The
+.Fn realloc
+function changes the size of the previously allocated memory referenced by
+.Fa addr
+to
+.Fa size
+bytes.
+The contents of the memory are unchanged up to the lesser of the new and
+old sizes.
+Note that the returned value may 

Re: gcc -O broken in CURRENT

[Kris Kennaway]

On Tue, Mar 12, 2002 at 01:49:02AM +0100, Martin Blapp wrote:
 
 Hi all,
 
 Here are my test news. The -O bug doesn't happen with
 gcc295 from ports !

Since this problem was apparently introduced recently, can you check
the commits against the gcc code in -current with the patches to the
port?  Presumably one or more commits have not yet appeared as
patches, and one of those is likely to be the cause.

Kris



msg35991/pgp0.pgp
Description: PGP signature

Re: Adding realloc()

[Alfred Perlstein]

* Archie Cobbs [EMAIL PROTECTED] [020312 14:45] wrote:
 Alfred Perlstein writes:
   I've had the need for a realloc() in the kernel several times
   before and am having it once again. Finally figured it's time to
   do something about it.
  
  Where is the update to malloc(9)?  What about reallocf?
 
 Good points, thanks.. try this one instead.

That looks ok, afaik you could do some vm tricks to avoid having
to malloc/free when doing realloc()'s that are larger than PAGE_SIZE.

-Alfred

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

port: glibtop failure on -current / Gnome won't build

[Stephen L. Palmer]

On:
FreeBSD adam12.midearth.org 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sat
Mar  9 13:55:57 CST 2002 [EMAIL PROTECTED]:/usr2/obj/usr/src/sys/MIDEARTH  i386

make of libgtop fails with the following error, causing a make of
/usr/ports/x11/gnome to fail...  any suggestions?

[snip]
cc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP -D_GNU_SOURCE
-DGLIBTOP_NAMES -I../.. -I../.. -I../../sysdeps/freebsd -I../../include
-I../../intl -I/usr/X11R6/include/gnome-1.0 -I/usr/X11R6/include
-DNEED_GNOMESUPPORT_H -I/usr/X11R6/lib/gnome-libs/include
-I/usr/local/include/glib12 -I/usr/local/include/orbit-1.0
-I/usr/X11R6/include/gtk12 -I/usr/local/include
-I/usr/local/include/glib12 -O -pipe -Wall -Wunused -I/usr/local/include
-I/usr/X11R6/include -DGLIBTOP_GUILE -DGLIBTOP_GUILE_NAMES
-I/usr/local/include -DGTOPLOCALEDIR=\/usr/local/share/gnome/locale\
-DLIBGTOP_VERSION=\1.0.13\ -DLIBGTOP_SERVER_VERSION=\5\
-DLIBGTOP_VERSION_CODE=113
-DLIBGTOP_SERVER=\/usr/local/bin/libgtop_server\ -I/usr/local/include -O
-pipe -Wall -Wunused -I/usr/local/include -c proctime.c  -fPIC -DPIC -o proctime.o
proctime.c: In function `calcru':
proctime.c:88: aggregate value used where an integer was expected
proctime.c:69: warning: unused variable `tv'
proctime.c: In function `glibtop_get_proc_time_p':
proctime.c:130: warning: unused variable `pstats'
proctime.c:128: warning: unused variable `u_addr'
proctime.c: At top level:
proctime.c:62: warning: `calcru' defined but not used
gmake[3]: *** [proctime.lo] Error 1
gmake[3]: Leaving directory
`/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps/freebsd'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr2/ports/devel/libgtop/work/libgtop-1.0.13'
gmake: *** [all-recursive-am] Error 2
*** Error code 2

Stop in /usr2/ports/devel/libgtop.
*** Error code 1

Stop in /usr2/ports/devel/libgtop.
*** Error code 1

Stop in /usr2/ports/devel/libgtop.
*** Error code 1

Stop in /usr2/ports/devel/libgtop.
root on adam12:/usr/ports/devel/libgtop %


---
Stephen L. Palmer
[EMAIL PROTECTED]

Receipt of this  email does not  entitle you to collect,
use, or sell my personal information for any commercial,
or  non-commercial purposes.   Non-solicited  commercial
emails  sent  to my address will be  billed $500.00  per
offense  for use of  storage space on my  mail  servers,
bandwidth  fees, and personal  administrative  overhead.
You have been warned.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Adding realloc()

[Archie Cobbs]

Alfred Perlstein writes:
I've had the need for a realloc() in the kernel several times
before and am having it once again. Finally figured it's time to
do something about it.
   
   Where is the update to malloc(9)?  What about reallocf?
  
  Good points, thanks.. try this one instead.
 
 That looks ok, afaik you could do some vm tricks to avoid having
 to malloc/free when doing realloc()'s that are larger than PAGE_SIZE.

Yeah I was wondering about that  how hard it would be.
That'd be the next step I guess.. thanks for the comments.

-Archie

__
Archie Cobbs * Packet Design * http://www.packetdesign.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: 4.5-5.0 kldxref:No such file or directory

[Crist J. Clark]

On Tue, Mar 12, 2002 at 02:05:06PM -0700, [EMAIL PROTECTED] wrote:
 
 make DESTDIR=/5.0 world kernel encountered the following problem:
 
 [...]
   --
Kernel build for GENERIC completed on Tue Mar 12 20:26:10 GMT 2002
   --
 [...]
   --
Kernel build for GENERIC completed on Tue Mar 12 20:26:10 GMT 2002
   --
   cd /usr/obj/5.0/usr/src/sys/GENERIC;  MAKEOBJDIRPREFIX=/usr/obj  
MACHINE_ARCH=i3
 [...]
   === xe
   install -c -o root -g wheel -m 555   if_xe.ko /5.0/boot/kernel/
   kldxref /5.0/boot/kernel
   kldxref:No such file or directory
   *** Error code 1 (ignored)
^

Note.

 Since there is no kldxref in 4.5, this should probably included in
 the bootstrap process somehow.

A known issue. The install process deliberately ignores this as a
non-fatal error.
-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

eaccess(2) breaks execution of 4.x binaries on 5.x

[Kris Kennaway]

Subject says it all, really; this is the cause of part of my problems
in getting 5.x packages built on the bento cluster, because it seems
that /bin/sh has come to depend on this syscall.  Executing a 5.x
/bin/sh on a 4.x system causes a SIGSYS if it hits this code
(e.g. test -x /some/binary)

Can this syscall be MFCed soon?

Kris




msg35996/pgp0.pgp
Description: PGP signature

Re: 4.5-5.0 kldxref:No such file or directory

[Emiel Kollof]

* Crist J. Clark ([EMAIL PROTECTED]) wrote:
  *** Error code 1 (ignored)
 ^
 
 Note.
 
  Since there is no kldxref in 4.5, this should probably included in
  the bootstrap process somehow.
 
 A known issue. The install process deliberately ignores this as a
 non-fatal error.

Why not test for it like this (or similar): 

[ -x /usr/sbin/kldxref ]  /usr/bin/kldxref (etcetera...)

If the new CURRENT testers upgrading from STABLE don't see it, 
they aren't likely to worry/complain about it. I think the warning is 
kinda nonsensical and redundant, IMHO. 

Cheers,
Emiel
-- 
It's raisins that make Post Raisin Bran so raisiny ...

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: eaccess(2) breaks execution of 4.x binaries on 5.x

[Kris Kennaway]

On Tue, Mar 12, 2002 at 07:12:11PM -0800, Kris Kennaway wrote:
 Subject says it all, really

Herf.  Subject is the wrong way around; this breaks execution of 5.x
binaries under 4.x, not the other way around.

 ; this is the cause of part of my problems
 in getting 5.x packages built on the bento cluster, because it seems
 that /bin/sh has come to depend on this syscall.

Actually it's /bin/test.

Kris



msg35998/pgp0.pgp
Description: PGP signature

automatic reboot without panic writing to local fat32 fs

[Riccardo Torrini]

Copying remote files (large backup, 200/300Megs) from my home
file server (4.5-STABLE) using nfs or ftp or scp to a local
msdos fat32 partition reboot machine without any error  :-(
Yes, local machine that has msdos mounted fs is -CURRENT:
# uname -v
FreeBSD 5.0-CURRENT #22: Tue Mar  5 20:50:06 CET 2002...

I completely destroy two partitions, trashed filesystem and
lost all contents (ok, it was backuped ;) copying files over
them.  I need a format from floppy to resume.
I was even unable to remove some strange named files (files
with non ascii-7 chars I suppose).

Initially I think to a nfs related problem, but it happens even
using ftp and scp, not only cp.
I splitted large files into smaller ones, 8Megs each, and tryed
to copy into a foreach loop, pausing 10/15secs between copies.
But it reboot all the times, and _all_ means a very high number
(I lost the count, but over 20).

All the (unwanted) test was with and without X, fsck-ing in
single user by hand (just to be informed of what get lost).

Activity led stay solid-rock-on all the copy time, after 70/80
Megs mouse locks up for a while and then machine reboot without
any other message.

Again, copying to a local ufs fs and than from local ufs to
local fat32 works fine (I just finished to restore them).

NB: I used this config on the last 3 years, upgrading both
server (now 4.5) and my machine at least once at a month.

Copying from local ufs or fat32 to remote nfs file server work
fine (for now :-).

If some dmesg, /var/log/messages or kernel config can help I
can post to list or provide a link to my home ftp/http to save
bandwidth and don't flood the list.


Riccardo.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: eaccess(2) breaks execution of 4.x binaries on 5.x

[Robert Watson]

On Tue, 12 Mar 2002, Kris Kennaway wrote:

 Subject says it all, really; this is the cause of part of my problems in
 getting 5.x packages built on the bento cluster, because it seems that
 /bin/sh has come to depend on this syscall.  Executing a 5.x /bin/sh on
 a 4.x system causes a SIGSYS if it hits this code (e.g. test -x
 /some/binary) 
 
 Can this syscall be MFCed soon? 

Today it's eaccess(), tomorrow it's KSE system calls, ACL system calls,
MAC system calls, 64-bit stat and ino_t, dev_t, devfs, ... 

Certainly we can MFC eaccess(), but that's not going to make the problem
go away.  Fundamentally our model is backward compatibility, not forward
compatibility.  We need to build 5.0 packages on 5.0. 

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: eaccess(2) breaks execution of 4.x binaries on 5.x

[Kris Kennaway]

On Tue, Mar 12, 2002 at 10:59:07PM -0500, Robert Watson wrote:
 
 On Tue, 12 Mar 2002, Kris Kennaway wrote:
 
  Subject says it all, really; this is the cause of part of my problems in
  getting 5.x packages built on the bento cluster, because it seems that
  /bin/sh has come to depend on this syscall.  Executing a 5.x /bin/sh on
  a 4.x system causes a SIGSYS if it hits this code (e.g. test -x
  /some/binary) 
  
  Can this syscall be MFCed soon? 
 
 Today it's eaccess(), tomorrow it's KSE system calls, ACL system calls,
 MAC system calls, 64-bit stat and ino_t, dev_t, devfs, ... 
 
 Certainly we can MFC eaccess(), but that's not going to make the problem
 go away.  Fundamentally our model is backward compatibility, not forward
 compatibility.  We need to build 5.0 packages on 5.0. 

Well, I've backed out the eaccess() use in /bin/test for now.  I agree
with you that ultimately this model will fail, but the longer we can
delay it the easier my life will be trying to manage the cluster and
get packages built.

I haven't yet tested the stability of 5.0 clients in the bento
cluster; hopefully it won't be too bad, but any stability problems
cause interruptions and increased work for me.  For example, for some
reason the gohan machines won't reboot on their own in response to a
reboot command, and have to be power cycled (they mostly come back up
okay if they panic, but sometimes they get stuck and need power
cycling still).  This means I can't currently automate booting them
into a 5.0 nfs snapshot when I want to build 5.0 packages.

Kris



msg36001/pgp0.pgp
Description: PGP signature

Re: eaccess(2) breaks execution of 4.x binaries on 5.x

[Makoto Matsushita]

rwatson Certainly we can MFC eaccess(), but that's not going to make
rwatson the problem go away.  Fundamentally our model is backward
rwatson compatibility, not forward compatibility.  We need to build
rwatson 5.0 packages on 5.0.

That's why I build FreeBSD 5-current snapshots on a 5-current box.

Note that we have already experienced such a situation before (at
least in September 1999, sigset_t change).

-- -
Makoto `MAR' Matsushita

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

MAKEDEV - Installation fails - 20020312

[Jeff Kletsky]

Installing on a Sony VAIO PCG-SRX7E/P
Boot from 4.5-INSTALL CD (iLINK)

set hw.pcic.intr_path=1
set hw.pcic.irq=0
boot

Visual configuration, leave only:
ata0
atkbd0
psm0
sc0
pcic0
npx0

Partition disk, select Developer and Ports

Select 5.0-20020312-CURRENT as release
Select -CURRENT FTP installation site

DHCP configuration of fxp0

watch all distributions get installed

Message MAKEDEV returned non-zero status

debug console shows a long series of

pid 199 (sh), uid 0: exited on signal 12 (core dumped)
Bad system call - core dumped
pid 201 (sh), uid 0: exited on signal 12 (core dumped)
Bad system call - core dumped
pid 203 (sh), uid 0: exited on signal 12 (core dumped)
Bad system call - core dumped
pid 205 (sh), uid 0: exited on signal 12 (core dumped)
Bad system call - core dumped


Expect that this is probably due to the incompatibilities between the
4.5-RELEASE /stand/sysinstall and the 5.0 MAKEDEV

Plan: try to create a bootable CD with a 5.0 kernel...

Nero Burning ROM, select CD-ROM (Boot), boot.flp, Floppy Emulation 2.88MB
Load segment of sectors (hex): 07C0  [jmk - their default]
Number of loaded sectors: 1  [jmk - their default]

set hw.pcic.intr_path=1
set hw.pcic.irq=0
boot

ACPI autoload failed - no such file or directory
-
(crash dump appears)

set hw.pcic.intr_path=1
set hw.pcic.irq=0
set hint.acpi.0.disabled=1
boot

ACPI autoload failed - no such file or directory
-
(crash dump appears)


#
# Any additional suggestions???
#

System boots on partial install, however, there is no MAKEDEV in /dev
So I'm going to try 'make world kernel' and hope for the best...

Thanks!

Jeff




(4.5-INSTALL) dmesg output follows:

Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.5-RELEASE #2: Tue Jan 29 22:44:12 GMT 2002
[EMAIL PROTECTED]:/usr/src/sys/compile/BOOTMFS
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 794926962 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (794.93-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x6b1  Stepping = 1
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 266862592 (260608K bytes)
config intro
\^[[m\^[[H\^[[J\^[[3;26H\^[[m\^[[1m\^[[m\^[[6;11H\^[[m\^[[7m\^[[m\^[[7;11H\^[[m\^[[8;11H\^[[m\^[[11;3H\^[[m\^[[12;3H\^[[m\^[[13;3H\^[[m\^[[15;3H\^[[m\^[[16;3H\^[[m\^[[18;3H\^[[m\^[[19;3H\^[[m\^[[21;3H\^[[m\^[[7m\^[[m\^[[22;3H\^[[m\^[[1;1H\^[[6;11H\^[[m\^[[7;11H\^[[m\^[[7m\^[[m\^[[8;11H\^[[m\^[[1;1H\^[[m\^[[H\^[[J\^[[m\^[[H\^[[J\^[[1;1H\^[[m\^[[1;4H\^[[m\^[[1m\^[[m\^[[1m\^[[1;64H\^[[m\^[[1m\^[[m\^[[1m\^[[m\^[[1m\^[[10;1H\^[[m\^[[10;4H\^[[m\^[[1m\^[[m\^[[1m\^[[10;64H\^[[m\^[[1m\^[[18;1H\^[[m\^[[22;1H\^[[m\^[[m\^[[24;1H\^[[m\^[[24;1H\^[[m\^[[1m\^[[m\^[[1m\^[[m\^[[1m\^[[m\^[[1;46H\^[[m\^[[7m\^[[2;1H\^[[m\^[[2;1H\^[[3;1H\^[[m\^[[3;1H\^[[4;1H\^[[m\^[[4;1H\^[[5;1H\^[[m\^[[5;1H\^[[6;1H\^[[m\^[[6;1H\^[[7;1H\^[[m\^[[7;1H\^[[m\^[[8;1H\^[[m\^[[m\^[[9;1H\^[[m\^[[11;1H\^[[m\^[[11;1H\^[[12;1H\^[[m\^[[12;1H\^[[13;1H\^[[m\^[[13;1H\^[[14;1H\^[[m\^[[14;1H\^[[15;1H\^[[m\^[[15;1H\^[[16;1H\^[[m\^[[16;1H\^[[m\^[[17;1H\^[[m\^[[m\^[[19;1H\^[[m\^[[20;1H\^[[m\^[[21;1H\^[[m\^[[2;1H\^[[m\^[[7m\^[[m\^[[2!
3;1H\^[[m\^[[23;1H\^[[m\^[[m\^[[23;1H\^[[m\^[[23;1H\^[[m\^[[1m\^[[m\^[[1m\^[[m\^[[2;1H\^[[1;46H\^[[m\^[[7m\^[[2;1H\^[[m\^[[2;1H\^[[3;1H\^[[m\^[[3;1H\^[[4;1H\^[[m\^[[4;1H\^[[5;1H\^[[m\^[[5;1H\^[[6;1H\^[[m\^[[6;1H\^[[7;1H\^[[m\^[[7;1H\^[[8;1H\^[[m\^[[8;1H\^[[9;1H\^[[m\^[[9;1H\^[[m\^[[19;1H\^[[m\^[[20;1H\^[[m\^[[21;1H\^[[m\^[[2;1H\^[[m\^[[7m\^[[m\^[[23;1H\^[[m\^[[23;1H\^[[m\^[[m\^[[23;1H\^[[m\^[[23;1H\^[[m\^[[1m\^[[m\^[[1m\^[[m\^[[2;1H\^[[2;1H\^[[m\^[[m\^[[23;1H\^[[m\^[[23;1H\^[[m\^[[m\^[[23;1H\^[[m\^[[23;1H\^[[m\^[[1m\^[[m\^[[1m\^[[m\^[[2;1H\^[[m\^[[19;1H\^[[m\^[[20;1H\^[[m\^[[21;1H\^[[m\^[[21;2H\^[[m\^[[3;1H\^[[m\^[[7m\^[[m\^[[23;1H\^[[m\^[[23;1H\^[[m\^[[1m\^[[m\^[[1m\^[[m\^[[3;1H\^[[1;46H\^[[m\^[[7m\^[[2;1H\^[[m\^[[2;1H\^[[3;1H\^[[m\^[[3;1H\^[[4;1H\^[[m\^[[4;1H\^[[5;1H\^[[m\^[[5;1H\^[[6;1H\^[[m\^[[6;1H\^[[7;1H\^[[m\^[[7;1H\^[[8;1H\^[[m\^[[8;1H\^[[9;1H\^[[m\^[[9;1H\^[[11;1H\^[[m\^[[11;1H\^[[12;1H\^[[m\^[[12;1H\^[[13;1H\^[[m\^[[13;1H\^[[14;1H\^[[m\^[[14;1H\^[[15;1H\^[[m\^[[15;!
1H\^[[16;1H\^[[m\^[[16;1H\^[[m\^[[17;1H\^[[m\^[[m\^[[19;1H\^[[m\^[[20;1H\^[[m\^[[21;1H\^[[m\^[[21;2H\^[[m\^[[3;1H\^[[m\^[[7m\^[[m\^[[23;1H\^[[m\^[[23;1H\^[[m\^[[1m\^[[m\^[[1m\^[[m\^[[3;1H\^[[1;46H\^[[m\^[[7m\^[[2;1H\^[[m\^[[2;1H\^[[3;1H\^[[m\^[[3;1H\^[[4;1H\^[[m\^[[4;1H\^[[5;1H\^[[m\^[[5;1H\^[[6;1H\^[[m\^[[6;1H\^[[7;1H\^[[m\^[[7;1H\^[[8;1H\^[[m\^[[8;1H\^[[9;1H\^[[m\^[[9;1H\^[[11;1H\^[[m\^[[11;1H\^[[12;1H\^[[m\^[[12;1H\^[[13;1H\^[[m\^[[13;1H\^[[14;1H\^[[m\^[[14;1H\^[[15;1H\^[[m\^[[15;1H\^[[16;1H\^[[m\^[[16;1H\^[[m\^[[17;1H\^[[m\^[[m\^[[19;1H\^[[m\^[[20;1H\^[[m\^[[21;1H\^[[m\^[[21;2H\^[[m\^[[3;1H\^[[m\^[[7m\^[[m\^[[23;1H\^[[m\^[[23;1H\^[[m\^[[1m\^[[m\^[[1m\^[[m\^[[3;1H\^[[1;46H

Re: port: glibtop failure on -current / Gnome won't build

[Joe Clarke]

On Tue, 2002-03-12 at 20:06, Stephen L. Palmer wrote:
 On:
 FreeBSD adam12.midearth.org 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sat
 Mar  9 13:55:57 CST 2002 [EMAIL PROTECTED]:/usr2/obj/usr/src/sys/MIDEARTH  
i386
 
 make of libgtop fails with the following error, causing a make of
 /usr/ports/x11/gnome to fail...  any suggestions?

This patch should fix it.  Just replace the original
files/patch-sysdeps::freebsd::proctime::c with the attached version, and
rebuild.  I'm building a PR now.

Joe

 
 [snip]
 cc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP -D_GNU_SOURCE
 -DGLIBTOP_NAMES -I../.. -I../.. -I../../sysdeps/freebsd -I../../include
 -I../../intl -I/usr/X11R6/include/gnome-1.0 -I/usr/X11R6/include
 -DNEED_GNOMESUPPORT_H -I/usr/X11R6/lib/gnome-libs/include
 -I/usr/local/include/glib12 -I/usr/local/include/orbit-1.0
 -I/usr/X11R6/include/gtk12 -I/usr/local/include
 -I/usr/local/include/glib12 -O -pipe -Wall -Wunused -I/usr/local/include
 -I/usr/X11R6/include -DGLIBTOP_GUILE -DGLIBTOP_GUILE_NAMES
 -I/usr/local/include -DGTOPLOCALEDIR=\/usr/local/share/gnome/locale\
 -DLIBGTOP_VERSION=\1.0.13\ -DLIBGTOP_SERVER_VERSION=\5\
 -DLIBGTOP_VERSION_CODE=113
 -DLIBGTOP_SERVER=\/usr/local/bin/libgtop_server\ -I/usr/local/include -O
 -pipe -Wall -Wunused -I/usr/local/include -c proctime.c  -fPIC -DPIC -o proctime.o
 proctime.c: In function `calcru':
 proctime.c:88: aggregate value used where an integer was expected
 proctime.c:69: warning: unused variable `tv'
 proctime.c: In function `glibtop_get_proc_time_p':
 proctime.c:130: warning: unused variable `pstats'
 proctime.c:128: warning: unused variable `u_addr'
 proctime.c: At top level:
 proctime.c:62: warning: `calcru' defined but not used
 gmake[3]: *** [proctime.lo] Error 1
 gmake[3]: Leaving directory
 `/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps/freebsd'
 gmake[2]: *** [all-recursive] Error 1
 gmake[2]: Leaving directory
 `/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps'
 gmake[1]: *** [all-recursive] Error 1
 gmake[1]: Leaving directory
 `/usr2/ports/devel/libgtop/work/libgtop-1.0.13'
 gmake: *** [all-recursive-am] Error 2
 *** Error code 2
 
 Stop in /usr2/ports/devel/libgtop.
 *** Error code 1
 
 Stop in /usr2/ports/devel/libgtop.
 *** Error code 1
 
 Stop in /usr2/ports/devel/libgtop.
 *** Error code 1
 
 Stop in /usr2/ports/devel/libgtop.
 root on adam12:/usr/ports/devel/libgtop %
 
 
 ---
 Stephen L. Palmer
 [EMAIL PROTECTED]
 
 Receipt of this  email does not  entitle you to collect,
 use, or sell my personal information for any commercial,
 or  non-commercial purposes.   Non-solicited  commercial
 emails  sent  to my address will be  billed $500.00  per
 offense  for use of  storage space on my  mail  servers,
 bandwidth  fees, and personal  administrative  overhead.
 You have been warned.
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-ports in the body of the message
 




proctime.c.gz
Description: GNU Zip compressed data


signature.asc
Description: This is a digitally signed message part

Re: eaccess(2) breaks execution of 4.x binaries on 5.x

[Maxim Konovalov]

Kris, Robert,

On 20:11-0800, Mar 12, 2002, Kris Kennaway wrote:

 On Tue, Mar 12, 2002 at 10:59:07PM -0500, Robert Watson wrote:
 
  On Tue, 12 Mar 2002, Kris Kennaway wrote:
 
   Subject says it all, really; this is the cause of part of my problems in
   getting 5.x packages built on the bento cluster, because it seems that
   /bin/sh has come to depend on this syscall.  Executing a 5.x /bin/sh on
   a 4.x system causes a SIGSYS if it hits this code (e.g. test -x
   /some/binary)
  
   Can this syscall be MFCed soon?
 
  Today it's eaccess(), tomorrow it's KSE system calls, ACL system calls,
  MAC system calls, 64-bit stat and ino_t, dev_t, devfs, ...
 
  Certainly we can MFC eaccess(), but that's not going to make the problem
  go away.  Fundamentally our model is backward compatibility, not forward
  compatibility.  We need to build 5.0 packages on 5.0.

 Well, I've backed out the eaccess() use in /bin/test for now.  I agree
 with you that ultimately this model will fail, but the longer we can
 delay it the easier my life will be trying to manage the cluster and
 get packages built.

I can replace my eaccess(2) patch for test(1) by a workaround I am
planning to commit to -stable. Is it desirable solution?

Index: test.c
===
RCS file: /home/ncvs/src/bin/test/test.c,v
retrieving revision 1.29.2.4
diff -u -r1.29.2.4 test.c
--- test.c  6 Feb 2002 17:37:13 -   1.29.2.4
+++ test.c  24 Feb 2002 21:26:38 -
@@ -195,6 +195,8 @@
int argc;
char **argv;
 {
+   gid_t   gid, egid;
+   uid_t   uid, euid;
int i, res;
char*p;
char**nargv;
@@ -224,14 +226,20 @@
}

/* XXX work around the absence of an eaccess(2) syscall */
-   (void)setgid(getegid());
-   (void)setuid(geteuid());
+   gid = getgid();
+   egid = getegid();
+   uid = getuid();
+   euid = geteuid();
+   (void)setregid(egid, gid);
+   (void)setreuid(euid, uid);

t_wp = argv[1];
res = !oexpr(t_lex(*t_wp));

if (*t_wp != NULL  *++t_wp != NULL)
syntax(*t_wp, unexpected operator);
+   (void)setregid(gid, egid);
+   (void)setreuid(uid, euid);

return res;
 }

-- 
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: port: glibtop failure on -current / Gnome won't build

[Stephen L. Palmer]

Replaced file with the one you attached, did 'make clean' and 'make' and
got the following.


[snip]
cc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP -D_GNU_SOURCE -DGLIBTOP_NAMES -
I../.. -I../.. -I../../sysdeps/freebsd -I../../include -I../../intl -I/usr/X11R6
/include/gnome-1.0 -I/usr/X11R6/include -DNEED_GNOMESUPPORT_H -I/usr/X11R6/lib/g
nome-libs/include -I/usr/local/include/glib12 -I/usr/local/include/orbit-1.0 -I/
usr/X11R6/include/gtk12 -I/usr/local/include -I/usr/local/include/glib12 -O -pip
e -Wall -Wunused -I/usr/local/include -I/usr/X11R6/include -DGLIBTOP_GUILE -DGLI
BTOP_GUILE_NAMES -I/usr/local/include -DGTOPLOCALEDIR=\/usr/local/share/gnome/l
ocale\ -DLIBGTOP_VERSION=\1.0.13\ -DLIBGTOP_SERVER_VERSION=\5\ -DLIBGTOP_VE
RSION_CODE=113 -DLIBGTOP_SERVER=\/usr/local/bin/libgtop_server\ -I/usr/loc
al/include -O -pipe -Wall -Wunused -I/usr/local/include -c proctime.c  -fPIC -DPIC -o 
proctime.o
proctime.c: In function `calcru':
proctime.c:88: aggregate value used where an integer was expected
proctime.c:69: warning: unused variable `tv'
proctime.c: In function `glibtop_get_proc_time_p':
proctime.c:130: warning: unused variable `pstats'
proctime.c:128: warning: unused variable `u_addr'
proctime.c: At top level:
proctime.c:62: warning: `calcru' defined but not used
gmake[3]: *** [proctime.lo] Error 1
gmake[3]: Leaving directory
`/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps/freebsd'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr2/ports/devel/libgtop/work/libgtop-1.0.13'
gmake: *** [all-recursive-am] Error 2
*** Error code 2

Stop in /usr2/ports/devel/libgtop.
*** Error code 1

Stop in /usr2/ports/devel/libgtop.
*** Error code 1

Stop in /usr2/ports/devel/libgtop.
root on adam12:/usr/ports/devel/libgtop %


---
Stephen L. Palmer
[EMAIL PROTECTED]


On 12 Mar 2002, Joe Clarke wrote:

 On Tue, 2002-03-12 at 20:06, Stephen L. Palmer wrote:
  On:
  FreeBSD adam12.midearth.org 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sat
  Mar  9 13:55:57 CST 2002 [EMAIL PROTECTED]:/usr2/obj/usr/src/sys/MIDEARTH  
i386
 
  make of libgtop fails with the following error, causing a make of
  /usr/ports/x11/gnome to fail...  any suggestions?

 This patch should fix it.  Just replace the original
 files/patch-sysdeps::freebsd::proctime::c with the attached version, and
 rebuild.  I'm building a PR now.

 Joe

 
  [snip]
  cc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP -D_GNU_SOURCE
  -DGLIBTOP_NAMES -I../.. -I../.. -I../../sysdeps/freebsd -I../../include
  -I../../intl -I/usr/X11R6/include/gnome-1.0 -I/usr/X11R6/include
  -DNEED_GNOMESUPPORT_H -I/usr/X11R6/lib/gnome-libs/include
  -I/usr/local/include/glib12 -I/usr/local/include/orbit-1.0
  -I/usr/X11R6/include/gtk12 -I/usr/local/include
  -I/usr/local/include/glib12 -O -pipe -Wall -Wunused -I/usr/local/include
  -I/usr/X11R6/include -DGLIBTOP_GUILE -DGLIBTOP_GUILE_NAMES
  -I/usr/local/include -DGTOPLOCALEDIR=\/usr/local/share/gnome/locale\
  -DLIBGTOP_VERSION=\1.0.13\ -DLIBGTOP_SERVER_VERSION=\5\
  -DLIBGTOP_VERSION_CODE=113
  -DLIBGTOP_SERVER=\/usr/local/bin/libgtop_server\ -I/usr/local/include -O
  -pipe -Wall -Wunused -I/usr/local/include -c proctime.c  -fPIC -DPIC -o proctime.o
  proctime.c: In function `calcru':
  proctime.c:88: aggregate value used where an integer was expected
  proctime.c:69: warning: unused variable `tv'
  proctime.c: In function `glibtop_get_proc_time_p':
  proctime.c:130: warning: unused variable `pstats'
  proctime.c:128: warning: unused variable `u_addr'
  proctime.c: At top level:
  proctime.c:62: warning: `calcru' defined but not used
  gmake[3]: *** [proctime.lo] Error 1
  gmake[3]: Leaving directory
  `/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps/freebsd'
  gmake[2]: *** [all-recursive] Error 1
  gmake[2]: Leaving directory
  `/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps'
  gmake[1]: *** [all-recursive] Error 1
  gmake[1]: Leaving directory
  `/usr2/ports/devel/libgtop/work/libgtop-1.0.13'
  gmake: *** [all-recursive-am] Error 2
  *** Error code 2
 
  Stop in /usr2/ports/devel/libgtop.
  *** Error code 1
 
  Stop in /usr2/ports/devel/libgtop.
  *** Error code 1
 
  Stop in /usr2/ports/devel/libgtop.
  *** Error code 1
 
  Stop in /usr2/ports/devel/libgtop.
  root on adam12:/usr/ports/devel/libgtop %
 
 
  ---
  Stephen L. Palmer
  [EMAIL PROTECTED]
 
  Receipt of this  email does not  entitle you to collect,
  use, or sell my personal information for any commercial,
  or  non-commercial purposes.   Non-solicited  commercial
  emails  sent  to my address will be  billed $500.00  per
  offense  for use of  storage space on my  mail  servers,
  bandwidth  fees, and personal  administrative  overhead.
  You have been warned.
 
 
  To Unsubscribe: send mail to [EMAIL PROTECTED]
  with unsubscribe freebsd-ports in the body of the message
 




To Unsubscribe: send mail to 

Re: eaccess(2) breaks execution of 4.x binaries on 5.x

[Julian Elischer]

any change that has to be added to 4.x tomake it run on 5.x is the wrong
answer.
4.x binaries should all run on 5.x (unless something was accidentally
committed to 4.x that should be backed out.)

any change for allowing 4.x binaries to run on  5.x should be done on the
5.x side of things,
(unless I've misunderstood the problem here)

regards, Julian


On Wed, 13 Mar 2002, Maxim Konovalov wrote:

 
 Kris, Robert,
 
 On 20:11-0800, Mar 12, 2002, Kris Kennaway wrote:
 
  On Tue, Mar 12, 2002 at 10:59:07PM -0500, Robert Watson wrote:
  
   On Tue, 12 Mar 2002, Kris Kennaway wrote:
  
Subject says it all, really; this is the cause of part of my problems in
getting 5.x packages built on the bento cluster, because it seems that
/bin/sh has come to depend on this syscall.  Executing a 5.x /bin/sh on
a 4.x system causes a SIGSYS if it hits this code (e.g. test -x
/some/binary)
   
Can this syscall be MFCed soon?
  
   Today it's eaccess(), tomorrow it's KSE system calls, ACL system calls,
   MAC system calls, 64-bit stat and ino_t, dev_t, devfs, ...
  
   Certainly we can MFC eaccess(), but that's not going to make the problem
   go away.  Fundamentally our model is backward compatibility, not forward
   compatibility.  We need to build 5.0 packages on 5.0.
 
  Well, I've backed out the eaccess() use in /bin/test for now.  I agree
  with you that ultimately this model will fail, but the longer we can
  delay it the easier my life will be trying to manage the cluster and
  get packages built.
 
 I can replace my eaccess(2) patch for test(1) by a workaround I am
 planning to commit to -stable. Is it desirable solution?
 
 Index: test.c
 ===
 RCS file: /home/ncvs/src/bin/test/test.c,v
 retrieving revision 1.29.2.4
 diff -u -r1.29.2.4 test.c
 --- test.c6 Feb 2002 17:37:13 -   1.29.2.4
 +++ test.c24 Feb 2002 21:26:38 -
 @@ -195,6 +195,8 @@
   int argc;
   char **argv;
  {
 + gid_t   gid, egid;
 + uid_t   uid, euid;
   int i, res;
   char*p;
   char**nargv;
 @@ -224,14 +226,20 @@
   }
 
   /* XXX work around the absence of an eaccess(2) syscall */
 - (void)setgid(getegid());
 - (void)setuid(geteuid());
 + gid = getgid();
 + egid = getegid();
 + uid = getuid();
 + euid = geteuid();
 + (void)setregid(egid, gid);
 + (void)setreuid(euid, uid);
 
   t_wp = argv[1];
   res = !oexpr(t_lex(*t_wp));
 
   if (*t_wp != NULL  *++t_wp != NULL)
   syntax(*t_wp, unexpected operator);
 + (void)setregid(gid, egid);
 + (void)setreuid(uid, euid);
 
   return res;
  }
 
 -- 
 Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
 phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: 4.5-5.0 kldxref:No such file or directory

[Crist J. Clark]

On Wed, Mar 13, 2002 at 04:13:35AM +0100, Emiel Kollof wrote:
 * Crist J. Clark ([EMAIL PROTECTED]) wrote:
 *** Error code 1 (ignored)
  ^
  
  Note.
  
   Since there is no kldxref in 4.5, this should probably included in
   the bootstrap process somehow.
  
  A known issue. The install process deliberately ignores this as a
  non-fatal error.
 
 Why not test for it like this (or similar): 
 
 [ -x /usr/sbin/kldxref ]  /usr/bin/kldxref (etcetera...)
 
 If the new CURRENT testers upgrading from STABLE don't see it, 
 they aren't likely to worry/complain about it. I think the warning is 
 kinda nonsensical and redundant, IMHO. 

The warning is just how make(1) works,

  # Calling kldxref(8) for each module is expensive.
  .if !defined(NO_XREF)
  .MAKEFLAGS:=${.MAKEFLAGS} -DNO_XREF
  afterinstall:
  -kldxref ${DESTDIR}${KMODDIR}
  .endif

-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: port: glibtop failure on -current / Gnome won't build

[Stephen L. Palmer]

My mistake,
  I guess it helps if I 'gzip -d' the patch  ;-)

Sorry about that, it seems to work great!

---
Stephen L. Palmer
[EMAIL PROTECTED]

On Tue, 12 Mar 2002, Stephen L. Palmer wrote:

 Replaced file with the one you attached, did 'make clean' and 'make' and
 got the following.


 [snip]
 cc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP -D_GNU_SOURCE -DGLIBTOP_NAMES -
 I../.. -I../.. -I../../sysdeps/freebsd -I../../include -I../../intl -I/usr/X11R6
 /include/gnome-1.0 -I/usr/X11R6/include -DNEED_GNOMESUPPORT_H -I/usr/X11R6/lib/g
 nome-libs/include -I/usr/local/include/glib12 -I/usr/local/include/orbit-1.0 -I/
 usr/X11R6/include/gtk12 -I/usr/local/include -I/usr/local/include/glib12 -O -pip
 e -Wall -Wunused -I/usr/local/include -I/usr/X11R6/include -DGLIBTOP_GUILE -DGLI
 BTOP_GUILE_NAMES -I/usr/local/include -DGTOPLOCALEDIR=\/usr/local/share/gnome/l
 ocale\ -DLIBGTOP_VERSION=\1.0.13\ -DLIBGTOP_SERVER_VERSION=\5\ -DLIBGTOP_VE
 RSION_CODE=113 -DLIBGTOP_SERVER=\/usr/local/bin/libgtop_server\ -I/usr/loc
 al/include -O -pipe -Wall -Wunused -I/usr/local/include -c proctime.c  -fPIC -DPIC 
-o proctime.o
 proctime.c: In function `calcru':
 proctime.c:88: aggregate value used where an integer was expected
 proctime.c:69: warning: unused variable `tv'
 proctime.c: In function `glibtop_get_proc_time_p':
 proctime.c:130: warning: unused variable `pstats'
 proctime.c:128: warning: unused variable `u_addr'
 proctime.c: At top level:
 proctime.c:62: warning: `calcru' defined but not used
 gmake[3]: *** [proctime.lo] Error 1
 gmake[3]: Leaving directory
 `/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps/freebsd'
 gmake[2]: *** [all-recursive] Error 1
 gmake[2]: Leaving directory
 `/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps'
 gmake[1]: *** [all-recursive] Error 1
 gmake[1]: Leaving directory
 `/usr2/ports/devel/libgtop/work/libgtop-1.0.13'
 gmake: *** [all-recursive-am] Error 2
 *** Error code 2

 Stop in /usr2/ports/devel/libgtop.
 *** Error code 1

 Stop in /usr2/ports/devel/libgtop.
 *** Error code 1

 Stop in /usr2/ports/devel/libgtop.
 root on adam12:/usr/ports/devel/libgtop %


 ---
 Stephen L. Palmer
 [EMAIL PROTECTED]


 On 12 Mar 2002, Joe Clarke wrote:

  On Tue, 2002-03-12 at 20:06, Stephen L. Palmer wrote:
   On:
   FreeBSD adam12.midearth.org 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sat
   Mar  9 13:55:57 CST 2002 [EMAIL PROTECTED]:/usr2/obj/usr/src/sys/MIDEARTH 
 i386
  
   make of libgtop fails with the following error, causing a make of
   /usr/ports/x11/gnome to fail...  any suggestions?
 
  This patch should fix it.  Just replace the original
  files/patch-sysdeps::freebsd::proctime::c with the attached version, and
  rebuild.  I'm building a PR now.
 
  Joe
 
  
   [snip]
   cc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP -D_GNU_SOURCE
   -DGLIBTOP_NAMES -I../.. -I../.. -I../../sysdeps/freebsd -I../../include
   -I../../intl -I/usr/X11R6/include/gnome-1.0 -I/usr/X11R6/include
   -DNEED_GNOMESUPPORT_H -I/usr/X11R6/lib/gnome-libs/include
   -I/usr/local/include/glib12 -I/usr/local/include/orbit-1.0
   -I/usr/X11R6/include/gtk12 -I/usr/local/include
   -I/usr/local/include/glib12 -O -pipe -Wall -Wunused -I/usr/local/include
   -I/usr/X11R6/include -DGLIBTOP_GUILE -DGLIBTOP_GUILE_NAMES
   -I/usr/local/include -DGTOPLOCALEDIR=\/usr/local/share/gnome/locale\
   -DLIBGTOP_VERSION=\1.0.13\ -DLIBGTOP_SERVER_VERSION=\5\
   -DLIBGTOP_VERSION_CODE=113
   -DLIBGTOP_SERVER=\/usr/local/bin/libgtop_server\ -I/usr/local/include -O
   -pipe -Wall -Wunused -I/usr/local/include -c proctime.c  -fPIC -DPIC -o 
proctime.o
   proctime.c: In function `calcru':
   proctime.c:88: aggregate value used where an integer was expected
   proctime.c:69: warning: unused variable `tv'
   proctime.c: In function `glibtop_get_proc_time_p':
   proctime.c:130: warning: unused variable `pstats'
   proctime.c:128: warning: unused variable `u_addr'
   proctime.c: At top level:
   proctime.c:62: warning: `calcru' defined but not used
   gmake[3]: *** [proctime.lo] Error 1
   gmake[3]: Leaving directory
   `/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps/freebsd'
   gmake[2]: *** [all-recursive] Error 1
   gmake[2]: Leaving directory
   `/usr2/ports/devel/libgtop/work/libgtop-1.0.13/sysdeps'
   gmake[1]: *** [all-recursive] Error 1
   gmake[1]: Leaving directory
   `/usr2/ports/devel/libgtop/work/libgtop-1.0.13'
   gmake: *** [all-recursive-am] Error 2
   *** Error code 2
  
   Stop in /usr2/ports/devel/libgtop.
   *** Error code 1
  
   Stop in /usr2/ports/devel/libgtop.
   *** Error code 1
  
   Stop in /usr2/ports/devel/libgtop.
   *** Error code 1
  
   Stop in /usr2/ports/devel/libgtop.
   root on adam12:/usr/ports/devel/libgtop %
  
  
   ---
   Stephen L. Palmer
   [EMAIL PROTECTED]
  
   Receipt of this  email does not  entitle you to collect,
   use, or sell my personal information for any commercial,
   or  non-commercial purposes.   Non-solicited  commercial
   emails  sent  to my address will be  

Re: eaccess(2) breaks execution of 4.x binaries on 5.x

[Maxim Konovalov]

On 21:33-0800, Mar 12, 2002, Julian Elischer wrote:

 any change that has to be added to 4.x tomake it run on 5.x is the wrong
 answer.
 4.x binaries should all run on 5.x (unless something was accidentally
 committed to 4.x that should be backed out.)

 any change for allowing 4.x binaries to run on  5.x should be done on the
 5.x side of things,
 (unless I've misunderstood the problem here)

I believe you have :-)

Kris cannot run /bin/sh from 5.x on 4.x because of absence eaccess(2)
in 4.x.

 regards, Julian


 On Wed, 13 Mar 2002, Maxim Konovalov wrote:

 
  Kris, Robert,
 
  On 20:11-0800, Mar 12, 2002, Kris Kennaway wrote:
 
   On Tue, Mar 12, 2002 at 10:59:07PM -0500, Robert Watson wrote:
   
On Tue, 12 Mar 2002, Kris Kennaway wrote:
   
 Subject says it all, really; this is the cause of part of my problems in
 getting 5.x packages built on the bento cluster, because it seems that
 /bin/sh has come to depend on this syscall.  Executing a 5.x /bin/sh on
 a 4.x system causes a SIGSYS if it hits this code (e.g. test -x
 /some/binary)

 Can this syscall be MFCed soon?
   
Today it's eaccess(), tomorrow it's KSE system calls, ACL system calls,
MAC system calls, 64-bit stat and ino_t, dev_t, devfs, ...
   
Certainly we can MFC eaccess(), but that's not going to make the problem
go away.  Fundamentally our model is backward compatibility, not forward
compatibility.  We need to build 5.0 packages on 5.0.
  
   Well, I've backed out the eaccess() use in /bin/test for now.  I agree
   with you that ultimately this model will fail, but the longer we can
   delay it the easier my life will be trying to manage the cluster and
   get packages built.
 
  I can replace my eaccess(2) patch for test(1) by a workaround I am
  planning to commit to -stable. Is it desirable solution?
 
  Index: test.c
  ===
  RCS file: /home/ncvs/src/bin/test/test.c,v
  retrieving revision 1.29.2.4
[...]

-- 
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: 4.5-5.0 kldxref:No such file or directory

[Emiel Kollof]

* Crist J. Clark ([EMAIL PROTECTED]) wrote:
 The warning is just how make(1) works,

AFAIK, you can use shell cmd's in bsd make...

   # Calling kldxref(8) for each module is expensive.
   .if !defined(NO_XREF)
   .MAKEFLAGS:=${.MAKEFLAGS} -DNO_XREF
   afterinstall:
   -kldxref ${DESTDIR}${KMODDIR}
   .endif


Maybe you could do something like this?

# Calling kldxref(8) for each module is expensive.
.if !defined(NO_XREF)
.MAKEFLAGS:=${.MAKEFLAGS} -DNO_XREF
afterinstall:
@if [ -x /usr/sbin/kldref ]; then \
kldxref ${DESTDIR}${KMODDIR}; \
fi
.endif

This approach seems to work for me.

Cheers,
Emiel
-- 
Langsam's Laws:
(1) Everything depends.
(2) Nothing is always.
(3) Everything is sometimes.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

$B7HBS5a?M>pJs%5!<%S%9(B

[kkjs]

$B7HBS5a?M>pJs%5!<%S%9!!L5NA%-%c%s%Z!<%s$N$*CN$i$;(B

$B$46=L#$N$J$$>pJs$G$7$?$i@?$K$*!W$K!!G[?.ITMW!!$H=q$-$4JV?.2<$5$$!#(B
ML$B$+$i:o=|$5$l$^$9!#$b$7$b%a!<%k$,=EJ#$7$?(B
$B>l9g$O$4MFpJs$rC5$;$^$9!#(B
$BJXMx$5$r0lEYpJs%5!<%S%9!JM-!K(B
$BEl5~ET3k>~6h>.4d#1CzL\#2#2HV#1#09f(B
e-mail [EMAIL PROTECTED]
HP http://www.kkjs.com/




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 4.5-5.0 kldxref:No such file or directory

[Emiel Kollof]

* Emiel Kollof ([EMAIL PROTECTED]) wrote:
 # Calling kldxref(8) for each module is expensive.
 .if !defined(NO_XREF)
 .MAKEFLAGS:=${.MAKEFLAGS} -DNO_XREF
 afterinstall:
   @if [ -x /usr/sbin/kldref ]; then \
   kldxref ${DESTDIR}${KMODDIR}; \
   fi
 .endif

Gah! I musn't stay up this late... :) s/kldref/kldxref

Cheers,
Emiel
-- 
Most people wouldn't know music if it came up and bit them on the ass.
-- Frank Zappa

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: 4.5-5.0 kldxref:No such file or directory

[David O'Brien]

On Wed, Mar 13, 2002 at 04:13:35AM +0100, Emiel Kollof wrote:
  A known issue. The install process deliberately ignores this as a
  non-fatal error.
 
 Why not test for it like this (or similar): 
 
 [ -x /usr/sbin/kldxref ]  /usr/bin/kldxref (etcetera...)
 
 If the new CURRENT testers upgrading from STABLE don't see it, 
 they aren't likely to worry/complain about it. I think the warning is 
 kinda nonsensical and redundant, IMHO. 

It would be better to teach users how to understand make.
If people are sending bogus bug reports due to this; I can imgine many
others we will get.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message