adjust conf/files and modules' Makefiles accordingly.
No code or ABI changes so this and most of previous related
changes can be easily MFC'ed
MFC after: 5 days
could be handled w/o fragmentation but clobbers user-specified values
such as those required when the interface is bridged.
Submitted by: jim@netgate.com
Reviewed by: Jouni Malinen
MFC after: 3 days
pipes, queues, tags, rule numbers and so on.
These are all different namespaces, and the only thing they have in
common is the fact they use a 16-bit slot to represent the argument.
There is some confusion in the code, mostly for historical reasons,
on how the values 0 and 65535 should be used. At the moment, 0 is
forbidden almost everywhere, while 65535 is used to represent a
'tablearg' argument, i.e. the result of the most recent table() lookup.
For now, try to use explicit constants for the min and max allowed
values, and do not overload the default rule number for that.
Also, make the MTAG_IPFW declaration only visible to the kernel.
NOTE: I think the issue needs to be revisited before 8.0 is out:
the 2^16 namespace limit for rule numbers and pipe/queue is
annoying, and we can easily bump the limit to 2^32 which gives
a lot more flexibility in partitioning the namespace.
MFC after: 5 days
Clists were originally used by the TTY layer as a text buffer interface.
The advantage of clists were that it would allocate a small set of
additional buffers that could be shared between TTYs when needed. In
the modern days we can just allocate some more KBs of memory to keep the
TTYs satisfied. The global cfreelist also requires synchronisation,
which may not be useful when trying to improve scalability.
The MPSAFE TTY layer uses its own text buffers (ttyinq and ttyoutq). We
had a small amount of drivers in the tree that still uses clists, like
the old USB stack and some keyboard drivers. With the old USB stack gone
and the keyboard drivers changed to use a circular buffer, we can safely
remove clists from the kernel.
These two drivers seem to be the last consumers of clists. clists are
quite overengineered for simple circular buffers, so I'm adding similar
buffer management routines to the kbd and kbdmux drivers. The input
buffer is now part of the softc structures, instead of having
dynamically allocated cblocks.
and used in a large number of files, but also because an increasing number
of incorrect uses of MAC calls were sneaking in due to copy-and-paste of
MAC-aware code without the associated opt_mac.h include.
Discussed with: pjd
structure contents are a bad idea in the kernel for binary
compatibility reasons, and this is a single pointer that is now included
in compiles by default anyway due to options MAC being in GENERIC.
+ move ipfw and dummynet hooks declarations to raw_ip.c (definitions
in ip_var.h) same as for most other global variables.
This removes some dependencies from ip_input.c;
+ remove the IPFW_LOADED macro, just test ip_fw_chk_ptr directly;
+ remove the DUMMYNET_LOADED macro, just test ip_dn_io_ptr directly;
+ move ip_dn_ruledel_ptr to ip_fw2.c which is the only file using it;
To be merged together with rev 193497
MFC after: 5 days
In Portuguese, the names of the days of the week are not capitalized.
Also there is always a dash before "feira" in the names of the days.
For example: "segunda-feira" and not "segunda feira" (which has a
completely different meaning).
x_fmt is not correct either. The date separator should not be a dot
but a slash. Example: 31/12/2005 if far more used in Portugal than
31.12.2005.
References:
- a Portuguese online dictionary http://priberam.pt/dlpo/dlpo.aspx
- http://answers.com/days_of_the_week (there are translations to
various languages, including Portuguese, at the bottom of the
page)
- http://en.wikipedia.org/wiki/Week-day_names (there are translations
to various languages, including Portuguese, at the bottom of the
page)
- a Portuguese style guide
http://www.publico.clix.pt/nos/livro_estilo/16d-palavras.html
("datas" section)
PR: conf/58595
Submitted by: Chris Stenton <jacs@gnome.co.uk>
MFC after: 1 week
stuff to its own directory, and cleaning headers and dependencies:
In this commit:
+ remove one use of a typedef;
+ document dn_rule_delete();
+ replace one usage of the DUMMYNET_LOADED macro with its value;
No MFC planned until the cleanup is complete.
a KASSERT to handle it. People are likely to turn off INVARIANTS RSN
and loading an old module can cause garbage-in here.
I saw the issue with an older nvidia driver (x11/nvidia-driver) loading
into a new kernel - a crash wasn't seen 'till sysctl_kern_malloc_stats().
I was lucky that mtp->ks_shortdesc was NULL and not something horrible.
While I'm here, KASSERT that malloc_uninit() isn't passed something that's
not in kmemstatistics.
MFC after: 3 weeks
Without this fix pte_vatopa() was not able to retrieve physical address of
data structures inside kernel, for example EFAULT was reported while acessing
/dev/kmem ('netstat -nr').
Submitted by: Piotr Ziecik
Obtained from: Semihalf
trying to open files rather than giving up when it encounters an
error. ENOENT errors are not reported.
As a result, files that are moved away then recreated are not at
risk of being 'lost' to tail. Files that are recreated and
temporarily have unreadable permissions will be shown when they
are fixed.
This behaviour is consistent with the GNU version of tail but
without the verbiage that goes with the GNU version.
This change also fixes error messages accompanying -f and -F.
They no longer report problems with (null)!
MFC after: 3 weeks
try to load modules by filename out of the current directory where the module
in question may be further up the module path or not in the module path at all.
Also add some text to the man page to help explain what's going on.
Sponsored by: Redacted Consulting
From the original PR:
s/milestones/millstones/
and less important..
s/man/Man/
Not every source I've seen capitalizes 'Man', but it seems
right. Uncapitalized 'man' would usually be preceded by
an 'a'. But I haven't seen any reference cite the orignal
source yet, so I can't say for sure.
http://quotationsbook.com/quote/31568/
PR: conf/131469
Submitted by: John Hein <jhein@timing.com>
MFC after: 2 days
Update the time in the fortune to make the joke a little bit more
realistic again: Bump year from 2009 to 2039.
PR: conf/129860
Submitted by: Alan Amesbury <amesbury@umn.edu>
MFC after: 2 days
