- in mount_portal.c: included catching of SIGHUP to get portald to
re-read the config file.
- in mount_portal.c: in SIGCHLD handler the return values checked from
waitpid were wrong. Note. this routine was written correclty according
to the manual page for 4.4BSD, but waitpid does not exhibit this
behaviour. It is not returning 0 when WNOHANG is specified. I havent
checked this properly.
- in mount_portal.c: initialized the fdset for the select properly.
- in mount_portal.c: corrected poor casting in the select.
- in mount_portal.c: changed a break; to exit (0); so that the
children die after doing the hard work, this stops the select: bad
file descriptor messages.
- in pt_file.c: the kernel passes kernel style open flags to the
portal code which aren't compatible with "normal" O_ flags. I have
adjusted these in pt_file.c. In general I think the portal fs code
and portal_cred structure need changing to pass to the portald
the right style of flags _and_ the permissions.
- in pt_tcp.c: a few mistakes in typing of the socket structures,
getservbyname returns the port number as an int but sockaddr wants
the port number as an u_short.
- in pt_tcp.c: someone wrote this on a VAX/Sun whatever and forget
about byte ordering!! I've included a few htons about the place.
- in all the above I have sprinkled a few more debugging printf's.
Submitted by: "Duncan McL Barclay" <dmlb@ohm.york.ac.uk
in a couple of cases, and it doesn't do much anyway. It used to save only
the newfs params (block/frag/cgroup.. and nothing more. Something that
don't belong in a disklabel in the first place.
- Add $Id$ string.
- Fix comment ("we might *not* be able to unload the
module afterwards without panicking...")
- Get rid of variable 'j' that I used in name checking
for(;;) loop and use 'i' instead (I thought there'd be
a problem with this, but there isn't).
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.
