Following Christos' idea I ended up with the patch below that works just fine.
I haven't even compile tested the mips part.
This removes #ifdef __mips__ in netbsd32 compat code, so I like it.
I'll commit this if no objections are raised.
Martin
Index: kern/init_sysctl_base.c
==
>> Disabling user opens, by any means, would make such things
>> significantly more difficult.
> Hmm, indeed. In the end we don't realy care as long as that open
> does not change the serial communication parameters.
I'm not sure even that is good. I have at least one Sun mouse which
runs at 960
On Fri, Oct 27, 2017 at 11:15:34AM -0400, Mouse wrote:
> Heh. Well, reading the x86 bus_dma implementation (amd64 doesn't seem
> to have a separate bus_dma implementation of its own) leads me to think
> it has no such issues; all POSTREAD does there is copy from the bounce
> buffer (if the tra
On Sun, Oct 29, 2017 at 10:41:18PM +0100, Jarom?r Dole?ek wrote:
> I share pretty much the same sentiment.
>
> ext3/ext4 journalling support is not very useful, as it's not likely to be
> used for anything more critical then sharing files between Linux and
> NetBSD.
Well... if the journaling
On Mon, Oct 30, 2017 at 12:14:13PM -0400, Mouse wrote:
> Disabling user opens, by any means, would make such things
> significantly more difficult.
Hmm, indeed. In the end we don't realy care as long as that open does
not change the serial communication parameters.
My initial try was to make sure
>> Now for those devices we definitively do not want userland access to
>> the com device. This would be pretty easy if we add another flag to
>> the tty line disciplines t_state member, like TS_NO_USER_OPEN.
>> Does that sound good? Other suggestions?
Not directly relevant to everyone, and not
On Sun, 29 Oct 2017, Martin Husemann wrote:
> Now for those devices we definitively do not want userland access to the com
> device. This would be pretty easy if we add another flag to the tty
> line disciplines t_state member, like TS_NO_USER_OPEN. Then we could
> modify comclose like:
> Does th
I see that there is some work done on ext3 and ext4, but only on read only
mode. Why wasnt this merged into the kernel? Are you guys waiting on it to be
complete ext3/ext4 support, as in with write support? And the project
description there specifically mentioned journaling and since ext3 is bac
I share pretty much the same sentiment.
ext3/ext4 journalling support is not very useful, as it's not likely to be
used for anything more critical then sharing files between Linux and
NetBSD. Ext3 journal would have to be complete reimplementation - NetBSD
wapbl is not usable nor sufficient for ex