i82586-based controller, similarily to e.g. ai(4), el(4) or ix(4).
The driver was modelled after the ai(4) driver.
Due to lack of better documentation, Linux 3c523 driver was used
to find out 3c523-specific quirks. Of course, the necessary work was greatly
reduced by our decend generic ic/i82586 code :)
Finally, NetBSD supports an ethernet card on IBM PS/2!
because neither "ypxfr" nor the YP bits of "libc" can handle IPv6. If the
hostname is used there will be an automatic fallback to IPv4 which makes
server pushed work again in mixed IPv4 and IPv6 environments. This fixes
bin/11755 by myself.
datagram that we received, which leads to easier support for
(ignoring) the procmail messages that specify the folder to which
the message was delivered.
When reading the mailbox, if we encounter a "From " line, we should
exit(). This can occur if there are a lot of rapidly arriving, yet
short messages.
- Adjust for the driver to be configured as fdisa
- Add a for the atari correct fd_types array
- Work around the fact that the atari has no machine/conf.h
Revert the revert. Naturally, I considered OpenBSD and FreeBSD when I fixed
the incorrect use of the spl*() interface. The change I made is _required_
for both NetBSD _and_ OpenBSD, or the code won't even COMPILE except on
i386, and it is acceptable on FreeBSD. Your revert and mod rebroke it on
OpenBSD and tangled things up on NetBSD. It made no difference on FreeBSD.
In particular, there are 2,895 uses of splx() within the FreeBSD kernel,
and only a mere 21, that's "twenty one" uses of intrmask_t, and those are
almost exclusively in the guts of the interrupt implementation, _not_ in
the _use_ of the exported spl*() functions. It's perfectly OK to `int s
= spltty()' in a portable driver in FreeBSD.
For that matter, FreeBSD (-current at least) does not even *use* spl*()
any more and stubs them all out with inlines that do _nothing_ except return
0, making intrmask_t vs int _even less_ important there than it already
was.
I think it's great that you want to start hacking on the kernel, but do
note that this is certainly the most simple of the kernel interfaces. It
just gets worse from here. Be careful out there!
The manual page for each system call will list some of the
common errno codes that system call can return, but that
should not be considered an exhaustive list, i.e. a properly
written program should be able to gracefully recover from
any error that a system call might return. Documenting
all the error codes that a system call can return in a more
specification-like manner would take more resources than
this project has available.
jdolecek