compile problem with usbdev on 5.0

Two days in a row I've had problems with make world when compiling usr.sbin/usbdevs.c. It appears the struct usb_device_info was changed. The following patch seems like it might be the right solution: brad --- usr.sbin/usbdevs.c.orig Mon Nov 22 18:16:10 1999 +++ usr.sbin/usbdevs.c Sat Fe

SIGBUS w/ 5.0-CURRENT + Imlib

I'm seeing a strange problem on 5.0 (c. Feb 19). It seem everything that uses the Imlib library (/usr/ports/graphics/imlib) dumps core with a SIGBUS when starting up. When I try to use gdb, I see that it is not even getting to main() before crashing. Has anyone seen anything like this before?

closeing files in detach()

There's a mention in the FBSD hacking guide that a detach() routine for a device driver can forcably close all open descriptors for its device before it unloads. How does one do this? brad To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the mes

Re: closeing files in detach()

>> There's a mention in the FBSD hacking guide that a detach() routine >> for a device driver can forcably close all open descriptors for >> its device before it unloads. >> >> How does one do this? > Check this out (from one of my USB device drivers I haven't yet > forced upon the world): > >

Re: closeing files in detach()

> I wrote the driver against -CURRENT, but browsing through > on a 4.4-STABLE box reveals that specfs is in use there, too. I haven't > been trying my driver out against -STABLE yet, but -CURRENT works just fine. > > typedef struct specinfo *dev_t; > ^ this is what I have in 4.4-STABLE. Oops..

Re: Kernel Debugging over the Ethernet?

>> IP is so you can make it through a cisco, etc. to another >> routable segment. > Oh I know that; but the cost of that convenience seems high. > For us, with a lab full of test machines (used for simulating > and testing various IP network clouds) a non-IP solution was > preferable. > But I

Re: ports & DESTDIR (was: STLPORT and gcc3 (openoffice porting))

> bsd.ports.mk uses DESTDIR differently (wrongly IMO) than FreeBSD's > buildworld or the rest of the world as far as I have seen. See (and > lobby for) ports/28155. Unfortunately, the fix in 28155 will make > DESTDIR behave the "right" way, and thus anyone expecting the "wrong" > behavior w