tl == Terry Lambert wrote:
tl FWIW: tail-call optimization is when I have a function
tl that, as it's last thing (perhaps after reordering by
tl the compiler, as well) calls another function, such
tl that the return value of the other function is its
tl return value.
See also:
Debunking
Michael Reifenberger wrote:
linux ls fails on DEVFS /dev because linux_getdents fails because
linux_getdents uses VOP_READDIR( ..., ncookies, cookies ) instead of
VOP_READDIR( ..., NULL, NULL ) because it seems to need the offsets for
linux_dirent and sizeof(dirent) != sizeof(linux_dirent)...
Er. Interesting. Doing some reading up on the M1533, I notice that the
power management component isn't actually listed here:
ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03
hdr=0x00
vendor = 'Acer Labs Inc.'
device = 'ALI M5237 USB Host
Hi.
Just upgraded my system today to the latest -current, after my
last venture into -current in May. Has MS-Dos filesystem
support been broken ? I can't see any commits or notes
in UPDATING, and hadn't read anything in -current about it.
I am running devfs.
Debugging output below :
FreeBSD
Hello,
() are missing around the KASSERT format string in aac.c and compilation
fails (if KASSERTS are enabled). The following patch fixes the problem.
Regards,
harti
Index: aac.c
===
RCS file: /usr/ncvs/src/sys/dev/aac/aac.c,v
Hello,
I've added you to my freebsd-lists-for-dayan-only group at eGroups, a free,
easy-to-use email group service. As a member of this group, you
may send messages to the entire group using just one email address:
[EMAIL PROTECTED] eGroups also makes it easy to
store photos and files,
Hello,
Thanks for using eGroups, home to free, easy, email groups.
We have received your request for information about a forgotten
password.
* If you requested this notice and still don't remember your
password, please follow these steps to create a new
password:
1. In your web
While reading the exports(5) manpage, near the bottom is an example
kill -s HUP `cat /var/run/mountd.pid`
does kill -s causes this error:
# kill -s HUP
s: Unknown signal; kill -l lists signals.
However, reading the kill(1) manpage, -s is documented.
So, I am thinking this is a bug in kill(1).
On Tue, Aug 07, 2001 at 03:12:08PM -0400, David Hill wrote:
# kill -s HUP
s: Unknown signal; kill -l lists signals.
However, reading the kill(1) manpage, -s is documented.
So, I am thinking this is a bug in kill(1).
I bet you are using csh, and running the kill builtin instead of
kill(1).
On Tue, 07 Aug 2001 15:12:08 -0400, David Hill wrote:
However, reading the kill(1) manpage, -s is documented.
So, I am thinking this is a bug in kill(1).
Does anyone have any comments?
Read the kill(1) manual page:
Some shells may provide a builtin kill command which is similar or
At 3:12 PM -0400 8/7/01, David Hill wrote:
While reading the exports(5) manpage, near the bottom is an example
kill -s HUP `cat /var/run/mountd.pid`
does kill -s causes this error:
# kill -s HUP
s: Unknown signal; kill -l lists signals.
However, reading the kill(1) manpage, -s is documented.
I did an archive search of this list, and found a post from April from a guy who had
some diffs to scsi_da.c and the umass driver to
get this thing working. I sent him an email a couple of weeks ago, but haven't heard
back yet.
He said he had it working under -current.
Does anyone have a
Mike Smith schrieb:
Er. Interesting. Doing some reading up on the M1533, I notice that the
power management component isn't actually listed here:
ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03
hdr=0x00
vendor = 'Acer Labs Inc.'
device =
Now, this _used_ to work -- some time back in February or even in
spring. But not anymore... usbd is running, the usb device, with the
uhci are compiled into the kernel, and the controller is reported on
boot:
uhci0: Intel 82371AB/EB (PIIX4) USB controller port
In article [EMAIL PROTECTED],
Harti Brandt [EMAIL PROTECTED] wrote:
() are missing around the KASSERT format string in aac.c and compilation
fails (if KASSERTS are enabled). The following patch fixes the problem.
Index: aac.c
I'm surry I don't have much data to provide, but...
I've been experiencing random lockups on a -CURRENT kernel from the August
5th source. I've gotten it a lot when running screen and ssh on two
different terminals at the same time, but that is not the only time it
happens.
Hardware is a
Dear Registrant,
The most anticipated event since the first release of the dotcoms is here!
If you haven't already done so it's time to pre-register your .biz and .info
'Top Level Domain Names' and stake your claim in what is fast becoming a LAND
RUSH, larger than the .com phenomena.
On 07-Aug-01 Paul Saab wrote:
Kenneth D. Merry ([EMAIL PROTECTED]) wrote:
diff2 output, on the other hand, won't run through patch properly. You
have to run it through a fixup script to get it right.
p4 diff -u -b branch
p4 diff2 -u -b branch
^
--
John Baldwin [EMAIL PROTECTED]
On 07-Aug-01 Julian Elischer wrote:
I have pushed the thread pointers down through most of the code
though there are still many many places that assume that there is only one
thread per process. (no multithreading yet, but getting closer..)
At this stage diffs must be pushing close to
On Tue, Aug 07, 2001 at 09:36:01 -0700, John Baldwin wrote:
On 07-Aug-01 Julian Elischer wrote:
I have pushed the thread pointers down through most of the code
though there are still many many places that assume that there is only one
thread per process. (no multithreading yet, but
20 matches
Mail list logo
