got a 2.2 version DC21040 chip in my SMC ethernet card! He suggests bumping
the check all the way down to 2.0 since it's pre-2.0 we're actually guarding
against.
Submitted by: Matt Thomas <matt@lkg.dec.com>
"Building for WWW" (pops up in two different ports) "Installing for
web2c-6.1" (ditto), which aren even't reminiscent of the port's real
name.
Sorry jmz, please don't go fix the print Makefiles' own messages.
We are going to take them out after we do the great bsd.port.mk
update anyway.
if_tun_mod, etc...) from crashing the system. These modules are useful,
but because they don't yet have proper load()/unload() functions,
they can lead to panics: if, for example, you load the if_ppp module,
any user can panic the system by running modstat.
You can also hang the system outright if you try to unload the PPP
module too.
Changes are as follows:
- Save the name passed to us during the RESERVE stage for name matching
(we can't load if_ppp_mod twice: we've have two ppp0's and two ppp1's,
which is beyond strange). This makes the lkmexists() cheks somewhat
redundant, but there's no way around it that I can see.
- If we call the module entry point and find that we have no lkm_any
structure in our 'private' section, create a fake one. This keeps
modstat happy. We mark such modules as LM_UNKNOWN.
- Don't allow LM_UNLOAD modules to be unloaded: it just ain't
possible. (Unless someone wants to write a pppunattach() function. :( )
- In lkmunreserve(), mark private.lkm_any as NULL so we don't get
confused later. I think this is bogus, but I can't prove it.
XXX: the name matching used to keep the user from loading two
instances of the same module can easily be defeated simply by
changing the module name or, in the case of the oddball modules,
simply by renaming the module files. I haven't found a nice simple
way to tell one module from another.
covered now, and i've attempted to give textual representations
instead of magic numbers.
The st(4) driver still misses some pieces; i'm going to implement the
EOM functionality RSN.
Any takers for the MTCOMP command? Seems to have never been implemented.
the top level and have the build-package sequence of each port work
together.
For the old behavior (i.e, just go ahead and blindly pack everything up,
regardless of the contents of work/), there is a new target "repackage".
Since "build" depends on "configure", which depends on "patch", etc.,
this shouldn't disrupt any Makefile that doesn't break the dependency
chain.
The old behavior was very annoying because when I did a "make -k",
it would still try to go configure and build even if the extraction
failed.
The first problem I found was that descriptor 0 was being closed.
This happens because the modem variable is set to 0 to indicate
that it is not valid but there are not enough tests for the modem
variable being 0. You can see where I have done this in the patch.
Code in OpenModem() dups the modem descriptor if it is < 3. Once
this happened the modem was always open and an incomming call would
have getty and ppp reading the modem.
Descriptor 1 is closed when the quit command was executed from a
telnet connection. The next modem open returns descriptor 1
and this gets duped leaving the modem always open again.
The modem was not being closed when the connection dropped or was
closed from the other end. The UUCP lock was also not removed if
the modem could not be opened.
Reviewed by: Atsushi Murai <amurai@spec.co.jp>
Submitted by: John Capo <jc@irbs.com>
interested parties.
Make the loader refuse to load anything below 1 MB -- we didn't
support it since FreeBSD 2.0R. Avoid gratuitously wiping out the BIOS
variables or the loader.
