Re: CVS commit: src/sys
On Mon, Aug 31, 2015 at 11:59 PM, Masao Uebayashi wrote: > sys/netinet/in.c calls a function in sys/net/if_llatbl.c > sys/net/if_llatbl.c calls a function in sys/net/if_arp.c > > This doesn't look very good from modularity POV. Maybe if_llatbl.c > should not directly refer to if_arp.c functions. Yes, but if we decide to separate nexthop caches from the routing table, the code will be removed. So please wait until then. (If we decide to not, I'll just introduce a callback.) ozaki-r
Re: CVS commit: src/sys
Off course you can do "file if_llatbl.c a|b|c" and leave the burden of fixing modularity for future people. :)
Re: CVS commit: src/sys
sys/netinet/in.c calls a function in sys/net/if_llatbl.c sys/net/if_llatbl.c calls a function in sys/net/if_arp.c This doesn't look very good from modularity POV. Maybe if_llatbl.c should not directly refer to if_arp.c functions.
Re: CVS commit: src/usr.bin/config
On Sat, Aug 29, 2015 at 12:03:51PM +0900, Masao Uebayashi wrote:
> Such a hack is needed because config(1) has to generate rules
> explicitly for each *.[cS]. If you try to override a rule (e.g.
> compile this pmap_bootstrap.c with ${NOPROF_C}), it will be a
> duplicated rule.
>
> If *.[cS] -> *.o will be written using suffix rules, you can safely
> override rules. No order constraint too.
You may want to define an explicit dependency foo.o: foo.[cS] and then
rely on the suffix rule to supply the commands.
This saves make from having to hunt for the appropriate source file
and (probably) makes it easier to have MI fallback sources.
David
--
David Laight: da...@l8s.co.uk
Re: CVS commit: src
On Sat, Aug 29, 2015 at 02:07:46PM +, Masao Uebayashi wrote:
> Module Name: src
> Committed By: uebayasi
> Date: Sat Aug 29 14:07:46 UTC 2015
>
> Modified Files:
> src/sys/conf: Makefile.kern.inc files
> src/sys/sys: param.h
> src/usr.bin/config: defs.h gram.y mkmakefile.c
>
> Log Message:
> Convert MAXUSERS, take 2.
>
> Define MAXUSERS in opt_param.h and include it from sys/param.h, for more
> accurate dependency. Don't define -DMAXUSERS and add it to ${CPPFLAGS}.
> config(5)'s "maxusers" syntax doesn't change.
It is probably worth revisiting MAXUSERS.
After all the default (16 or 64?) is just enough for one person.
IIRC a lot of limits are based on it, most of which probably
predate the dynamic allocation of the relevant structures.
Limits for the total number of open files and processes (etc)
are probably better based on system memory size (or even
available memory/kva/swap).
I remember a fixed size hash table for uids that could be done
a better way, but everything else just set soft limits.
David
--
David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/gpl3
On Tue, Aug 11, 2015 at 10:26:43PM +0400, Alan Barrett wrote: > On Tue, 11 Aug 2015, David Laight wrote: > >The system should probably clean 'turds' from both /tmp and /var/tmp. > > That would be surprising, at least to me. > > I rely on /var/tmp/vi.recover being persistent, and I often > use /var/tmp as a place to stash work in progress that should survive a > reboot. I was thinking of stuff that is old, not deleting everything on reboot. David -- David Laight: da...@l8s.co.uk
