Hey tech@
Here's a patch that adds octeon's onboard rng chip as a source of
entropy. Currently I fire this off every second, which neither seemed to
increase the load on my ERL or produce duplicate outputs.
This patch also maps out the rnm register which controls the status of
the rng and entropy
On Tue, Oct 22, 2013 at 02:34, Alexander Hall wrote:
> On 10/22/13 02:09, Ted Unangst wrote:
>> I don't think the -l flag to pkill is useful. It's behavior is oddly
>> different from pgrep -l (and more different with pgrep/pkill -f). Or
>> rather, it's not just long output, but also turns on verbos
On 10/22/13 02:09, Ted Unangst wrote:
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode when
otherwise nothing would be printed. The only use c
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode when
otherwise nothing would be printed. The only use case I can think of
is "did I kill the ri
Le 21/10/2013 09:38, Theo de Raadt a écrit :
I don't get what's wrong with running execve on it. In all cases,
someone can load it through another executable.
Using ld.so does not imply "execve'ing it".
If I have an interpreter that I chmod as exec-only, I want this
interpreter to be world-lo
On 10/21/13 18:04, Jasper Lievisse Adriaanse wrote:
On Fri, Oct 11, 2013 at 11:46:39PM +0300, Artturi Alm wrote:
On 10/11/13 20:39, Markus Hennecke wrote:
On Sat, 5 Oct 2013, Artturi Alm wrote:
Current version attached, extract to /sys/arch/armv7 and read the short
notes file, no more out of
Hi tech --
Here's a diff to replace some backwards compat calls with their
new calls. The rest were long replaced; I'm assuming these went
unnoticed because they're both under an
#ifdef OCTEON_ETH_DEBUG
This was pointed out by William Orr in a
private email.
OK?
~Brian
Index: cn30xxgmx.c
On Fri, Oct 11, 2013 at 11:46:39PM +0300, Artturi Alm wrote:
> On 10/11/13 20:39, Markus Hennecke wrote:
> >On Sat, 5 Oct 2013, Artturi Alm wrote:
> >
> >>Current version attached, extract to /sys/arch/armv7 and read the short
> >>notes file, no more out of allwinner/ patches needed thanks to armv7
On Mon, Oct 21, 2013 at 09:05:04AM -0500, Vladimir Támara Patiño wrote:
> I agree full Unicode support is desirable, but IMHO having 8 bits
> collation is better than nothing (for example withouth it spanish
> speakers have to
> see ñ, á and other special symbols at the end of sorted results in
> p
On Mon, Oct 21, 2013 at 02:14:32PM +0200, Martin Pelikan wrote:
> Indeed, doing collation properly (i.e. with Unicode, not just 8 bit
> characters like FreeBSD does) really is a non-trivial effort.
>
> It requires some expertise in linguistics and a solid understanding
> of the unicode standard
On Mon, Oct 21, 2013 at 02:14:32PM +0200, Martin Pelikan wrote:
> > Applications don't care where a symbol comes from.
> > Build scripts and Makefiles might expect them to be in libc and
> > would need to link an additional library, but that's trivial to do.
>
> For all such ports? Ok then :-)
H
> Indeed, doing collation properly (i.e. with Unicode, not just 8 bit
> characters like FreeBSD does) really is a non-trivial effort.
>
> It requires some expertise in linguistics and a solid understanding
> of the unicode standard. You'd need to make use of something like ICU
> (icu-project.org)
On Mon, Oct 21, 2013 at 12:45:58AM +0200, Martin Pelikan wrote:
> > > > Obviously, our locale support still sucks, this patch is mostly
> > > > providing the API for filling the blanks later.
> >
> > Which blanks exactly? Locale features we don't have, such as collation?
>
> Yes. The features w
* Claudio Jeker [2013-10-21 11:20]:
> Can't we not just nuke altq? It is going to die anyway so why try to keep
> it alive?
no, sorry.
as much as keeping it was a mistake (wearing my programmer hat), the
painful work has been done already, and the feedback i got on it is
clear.
besides, newqueu
On Mon, Oct 21, 2013 at 12:04:14AM +0200, Martin Pelikan wrote:
> Hopefully the third time does the charm.
>
> The previous union approach to altq/newq bits was wrong, because
> switching back and forth was racy. This new diff then concatenates
> these structures like [ifqueue, hfsc_if, altq-bits
On 20/10/13(Sun) 12:09, Jeremy Evans wrote:
> On 10/20 03:52, Martin Pieuchot wrote:
> > [...]
>
> Thanks for responding. Here's a new diff that incorporates most of your
> suggestions. Unfortunately, using the existing quirks infrastructure
> doesn't work correctly, because the quirks API is ba
> I don't get what's wrong with running execve on it. In all cases,
> someone can load it through another executable.
Using ld.so does not imply "execve'ing it".
> If I have an interpreter that I chmod as exec-only, I want this
> interpreter to be world-loadable without thereby letting other
> us
On 10/20/13 21:54, Theo de Raadt wrote:
>> Indeed, the interpreter is not passed to execve. That's why I used
>> >'get executed'
>> >instead of
>> >'are executed'
>> >though the difference might not be clear.
>> >
>> >The kernel loads the interpreter, and the code of that interpreter
>> >ge
18 matches
Mail list logo
