The problem with fcntl(2) locks is that they are not inherited by child
processes. This breaks pidfile(3), where the common idiom is to open
and lock the PID file before daemonizing.
I found out that the input format of the Boemler list was different
than what the code expected: The last two fields were interpreted
as one. Checking the csv version of the list it showed that there
was sometimes a chipset number in the column before the card
description.
This is a rewrite to use the CSV format of the Boemler list. The
output is differently formatted: Instead of the "chip description",
it is now "description (chip)"
in Freescale system-on-chip devices.
The following algorithms and schemes are currently supported:
- 3DES, AES, DES
- MD5, SHA1, SHA256, SHA384, SHA512
Reviewed by: philip
Obtained from: Freescale, Semihalf
behavior for unicode support in UDF so as not to conflict with the MAC
Framework.
Note that Apple's XNU kernel also uses #ifdef MAC for the MAC Framework.
Suggested by: pjd
MFC after: 3 days
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
