Le 31/10/2020 à 23:58, Reinoud Zandijk a écrit :
Dear folks,
I've reworked the patch using the feedback I got from Maxime and had to
refactor some minor parts in the other code. I'm in the process of writing the
test-cases now but would like feedback for this solution in the meantime. It
ought
Le 29/10/2020 à 21:54, Reinoud Zandijk a écrit :
Dear folks,
i stumbled on an instruction that NVMM couldn't code and thus couldn't
emulate either. It was as stated the REPE CMPS (0xF3A7) instruction as stated
in https://c9x.me/x86/html/file_module_x86_id_279.html and confirmed by
disassembly
Le 09/06/2020 à 02:49, Kamil Rytarowski a écrit :
pg_jobc is a process group struct member counting the number of
processes with a parent capable of doing job control. Once reaching 0,
the process group is orphaned.
With the addition of asserts checking for pg_jobc > 0 (by maxv@), we
caught
Le 01/06/2020 à 03:06, Emmanuel Dreyfus a écrit :
Emmanuel Dreyfus wrote:
After upgrading to 9.0, I experienced crashes when enabling
ipfilter (backtrace below). I tried latest netbsd-9 kernel without
improvement.
In the meantime, I filed kern/55236 about the ipfilter regression in
NetBSD
[I am not subscribed to this list, so if you want to answer, make sure to CC me]
In order to explore error branches, and to test the kernel's ability to cope
with failures, it is often necessary to hard-trigger such failures.
Here is an implementation [1] for fault(4), a driver that allows to
Seems to me there is a bug in x86's bus_dmamap_sync(). When the DMA buffer
is an UIO, and we bounce, the 'offset' argument is not taken into account
properly.
We should do
copy uio+off into bouncebuf+off
but we do
copy uio+0 into bouncebuf+off
A quick glance shows that other
Le 02/01/2020 à 16:55, Emmanuel Dreyfus a écrit :
And indeed, studying the crash in ddb shows it happens when
accessing a physical address that is excluded by x86_fake_clusters()
but included by EFI memory map.
Note that x86_fake_clusters() is unsafe. It does not exclude the MMIO
pages,
Le 02/01/2020 à 19:29, Jason Thorpe a écrit :
On Jan 2, 2020, at 10:16 AM, co...@sdf.org wrote:
Hi folks,
urio(4) is a driver for Rio 500, an MP3 player released in 1999.
It recently received some discussion due to problems detected
during maxv's USB-fuzzing.
Well, not exactly, the concerns
Le 17/12/2019 à 15:44, Andrew Doran a écrit :
Typically with a character device, the kmod can get unloaded while an ioctl
is being executed on it.
That's solvable. Conceptually I think the main stumbling block is that
there are two layers at play which need to reconciled: specfs and devsw.
Le 17/12/2019 à 12:34, Kamil Rytarowski a écrit :
On 17.12.2019 09:16, Maxime Villard wrote:
Module Name: htdocs
Committed By: christos
Date: Tue Dec 17 01:03:49 UTC 2019
Modified Files:
htdocs/support/security: advisory.html index.html
Log Message:
new advisory
Le 17/12/2019 à 14:32, Kamil Rytarowski a écrit :
On 17.12.2019 14:19, Maxime Villard wrote:
Le 17/12/2019 à 12:34, Kamil Rytarowski a écrit :
On 17.12.2019 09:16, Maxime Villard wrote:
Module Name: htdocs
Committed By: christos
Date: Tue Dec 17 01:03:49 UTC 2019
Modified
Module Name:htdocs
Committed By: christos
Date: Tue Dec 17 01:03:49 UTC 2019
Modified Files:
htdocs/support/security: advisory.html index.html
Log Message:
new advisory
To generate a diff of this commit:
cvs rdiff -u -r1.140 -r1.141
Le 17/12/2019 à 02:53, Emmanuel Dreyfus a écrit :
Hello
The initial commit of multiboot for amd64 had a problem with kernel
linking that broke BIOS boot. I fixed the linker script, but in the
meantime, the multiboot option in amd64 was also commented out.
Is there any objection against
Le 06/12/2019 à 20:37, Mindaugas Rasiukevicius a écrit :
Maxime Villard wrote:
Le 06/12/2019 à 17:53, Andrew Doran a écrit :
On Fri, Dec 06, 2019 at 05:22:39PM +0900, Kengo NAKAHARA wrote:
/* Update the worker */
- worker_ci = hci;
+ atomic_swap_ptr(_ci, hci);
Why
Le 06/12/2019 à 17:53, Andrew Doran a écrit :
On Fri, Dec 06, 2019 at 05:22:39PM +0900, Kengo NAKAHARA wrote:
/* Update the worker */
- worker_ci = hci;
+ atomic_swap_ptr(_ci, hci);
Why atomic_swap_ptr() not atomic_store_relaxed()? I don't see any bug that
it fixes.
Le 06/12/2019 à 11:28, Andrew Doran a écrit :
> On Fri, Dec 06, 2019 at 10:27:20AM +0100, Maxime Villard wrote:
>
>> With 'worker_ci', there is an actual safety issue, because the compiler could
>> split the accesses and the hardware may not use atomics by default like x86.
&
Le 06/12/2019 à 10:00, Andrew Doran a écrit :
> Hi,
>
> On Fri, Dec 06, 2019 at 03:52:23PM +0900, Kengo NAKAHARA wrote:
>
>> There are some racy accesses in kern_runq.c detected by KCSAN. Those
>> racy access messages is so frequency that they cover other messages,
>> so I want to fix them.
Le 06/12/2019 à 07:52, Kengo NAKAHARA a écrit :
> Hi,
>
> There are some racy accesses in kern_runq.c detected by KCSAN. Those
> racy access messages is so frequency that they cover other messages,
> so I want to fix them. They can be fixed by the following patch.
>
>
>
Le 21/11/2019 à 23:08, David Young a écrit :
On Thu, Nov 21, 2019 at 07:19:51PM +0100, Maxime Villard wrote:
Le 18/11/2019 à 19:49, David Holland a écrit :
On Sun, Nov 17, 2019 at 02:35:43PM +, Mindaugas Rasiukevicius wrote:
> David Holland wrote:
> > > I see the pote
Le 18/11/2019 à 19:49, David Holland a écrit :
On Sun, Nov 17, 2019 at 02:35:43PM +, Mindaugas Rasiukevicius wrote:
> David Holland wrote:
> > > I see the potential source of confusion, but just think about: what
> > > could "atomic" possibly mean for loads or stores? A load is
Le 16/11/2019 à 15:31, Mindaugas Rasiukevicius a écrit :
Maxime Villard wrote:
Alright so let's add the macros with volatile (my initial patch). Which
name do we use? I actually like __{read,write}_racy().
I suggest __atomic_load_relaxed()/__atomic_store_relaxed().
What I don't like
Alright so let's add the macros with volatile (my initial patch). Which name do
we
use? I actually like __{read,write}_racy().
Le 11/11/2019 à 13:51, Joerg Sonnenberger a écrit :
On Mon, Nov 11, 2019 at 11:02:47AM +0100, Maxime Villard wrote:
Typically in sys/uvm/uvm_fault.c there are several lockless stat increments
like the following:
/* Increment the counters.*/
uvmexp.fltanget++;
Wasn't
Le 08/11/2019 à 13:40, Mindaugas Rasiukevicius a écrit :
Maxime Villard wrote:
They are "atomic" in a sense that they prevent from tearing, fusing and
invented loads/stores. Terms and conditions apply (e.g. they assume
properly aligned and word-sized accesses). Additionally,
Le 06/11/2019 à 23:41, Mindaugas Rasiukevicius a écrit :
Maxime Villard wrote:
- If we do not want to stick with the C11 API (its emulation), then I
would suggest to use the similar terminology, e.g. atomic_load_relaxed()
and atomic_store_relaxed(), or Linux READ_ONCE()/WRITE_ONCE
Le 06/11/2019 à 20:38, Mindaugas Rasiukevicius a écrit :
Maxime Villard wrote:
There are cases in the kernel where we read/write global memory
locklessly, and accept the races either because it is part of the design
(eg low-level scheduling) or we simply don't care (eg global stats
Le 06/11/2019 à 12:38, Martin Husemann a écrit :
On Wed, Nov 06, 2019 at 12:31:37PM +0100, Maxime Villard wrote:
__read_once(x)
__write_once(x, val)
The names are really not helpfull for understanding what is supposed to happen
here.
I don't know if you have a better
Currently /dev/nvmm has these permissions
c rw- --- --- root wheel
Which means the user has to tune the permissions manually. I would like to
introduce an "nvmm" group, and change the perms to
c rw- r-- --- root nvmm
This means that emulators will have to be setgid nvmm, or
Le 17/10/2019 à 19:39, Tobias Nygren a écrit :
Hi,
Since there were some concerns raised that this problem shouldn't be
fixed in the driver ...
https://mail-index.netbsd.org/source-changes/2019/10/15/msg109984.html
... I'm going partially back it out and commit this change instead.
To
Le 12/10/2019 à 02:01, Emmanuel Dreyfus a écrit :
Hello
I recently encountered a situation where I had to deal with variable
length structure at a time where kernel dynamic allocator was not
initialized.
Using alloca() to have the data allocated on stack seemed attractive,
but unfortunately
Le 26/09/2019 à 21:21, Mouse a écrit :
So why the hell are you throwing in statements like
immense trouble for little actual use.
Because this is true! Do you understand, or not? Pfff.
It's not me you were responding to here. But you appear to be falling
into a relatively common trap:
Le 26/09/2019 à 19:39, Martin Husemann a écrit :
Btw: I find it very strange that this proposal has no concrete proposal.
What compat options exactly do you want to disallow from auto loading?
What exact sysctls and semantics do you have in mind?
My proposal is the same as Taylor's, as I said
Le 26/09/2019 à 18:19, Kamil Rytarowski a écrit :
On 26.09.2019 15:55, Kamil Rytarowski wrote:
On 26.09.2019 15:06, Mouse wrote:
[...] compat_linux and compat_linux32 [...]
Keeping them enabled for the <1% users interested means keeping
vulnerabilities for the >99% who don't use these
Le 26/09/2019 à 18:15, Manuel Bouyer a écrit :
On Thu, Sep 26, 2019 at 05:28:11PM +0200, Maxime Villard wrote:
Le 26/09/2019 à 17:25, Brian Buhrow a écrit :
[...]
One implication of your proposal is that you'll disable the autoload
functionality, users will turn it back on, use
Le 26/09/2019 à 16:47, Manuel Bouyer a écrit :
On Thu, Sep 26, 2019 at 04:40:33PM +0200, Maxime Villard wrote:
Actually this is not clear. We have linux binaries in pkgsrc.
... And? We have 22000 packages in pkgsrc.
How is it relevant ? I install less than 200. But there is suse_base
Le 26/09/2019 à 17:25, Brian Buhrow a écrit :
[...]
One implication of your proposal is that you'll disable the autoload
functionality, users will turn it back on, use it, and be more vulnerable
than they are now because the primary developers aren't concern with making
things work or
Le 26/09/2019 à 17:15, Manuel Bouyer a écrit :
On Thu, Sep 26, 2019 at 05:10:01PM +0200, Maxime Villard wrote:
issues for a clearly marginal use case, and given the current general
^^^
This is where we dissagree. You guess it's marginal but there's
Le 26/09/2019 à 17:03, Manuel Bouyer a écrit :
On Thu, Sep 26, 2019 at 04:52:35PM +0200, Maxime Villard wrote:
Le 26/09/2019 à 16:47, Manuel Bouyer a écrit :
On Thu, Sep 26, 2019 at 04:40:33PM +0200, Maxime Villard wrote:
Actually this is not clear. We have linux binaries in pkgsrc
Le 26/09/2019 à 16:36, Manuel Bouyer a écrit :
On Thu, Sep 26, 2019 at 04:29:52PM +0200, Maxime Villard wrote:
Le 26/09/2019 à 16:22, Mouse a écrit :
Keeping them enabled for the <1% users interested means keeping
vulnerabilities for the >99% who don't use these features.
Are the
Le 26/09/2019 à 16:22, Mouse a écrit :
Keeping them enabled for the <1% users interested means keeping
vulnerabilities for the >99% who don't use these features.
Are the usage numbers really that extreme? Where'd you get them? I
didn't think there were any mechanisms in place that would allow
Le 26/09/2019 à 15:06, Mouse a écrit :
[...] compat_linux and compat_linux32 [...]
Keeping them enabled for the <1% users interested means keeping
vulnerabilities for the >99% who don't use these features.
Are the usage numbers really that extreme? Where'd you get them? I
didn't think
I recently made a big set of changes to fix many bugs and vulnerabilities in
compat_linux and compat_linux32, the majority of which have a security impact
bigger than the Intel CPU bugs we hear about so much. These compat layers are
enabled by default, so everybody is affected.
Secteam is in a
Le 02/07/2019 à 16:21, J. Hannken-Illjes a écrit :
It would work but unfortunately dtrace is a module and cannot
use PMAP_DIRECT_BASE aka. pmap_direct_base. These variables
are not visible from module context and don't exist if the
kernel is built with KASAN.
Not related to the issue (which
Le 12/09/2019 à 08:21, Maxime Villard a écrit :
Le 06/09/2019 à 15:09, Maxime Villard a écrit :
An idea for a feature similar to KMEM_GUARD - which I recently removed because
it was too weak and useless -, but this time at the pool layer, covering certain
specific pools, without memory
Le 06/09/2019 à 15:09, Maxime Villard a écrit :
An idea for a feature similar to KMEM_GUARD - which I recently removed because
it was too weak and useless -, but this time at the pool layer, covering certain
specific pools, without memory consumption or performance cost, and enabled by
default
Le 08/09/2019 à 08:54, Jason Thorpe a écrit :
On Sep 8, 2019, at 9:29 AM, Maxime Villard wrote:
Don't confuse VA and PA. NetBSD-amd64 supports 16TB of PA, so even if
you have 48TB nvdimms it gets truncated to 16TB. Then, we have 32TB
of VA, twice more than the maximum PA. So again, we are fine
Le 07/09/2019 à 23:47, matthew green a écrit :
No performance cost, because these guarded buffers are allocated only when the
pools grow, which is a rare operation that occurs almost only at boot time. No
actual memory consumption either, because unmapped areas don't consume physical
memory,
An idea for a feature similar to KMEM_GUARD - which I recently removed because
it was too weak and useless -, but this time at the pool layer, covering certain
specific pools, without memory consumption or performance cost, and enabled by
default at least on amd64. Note that this is hardening and
https://www.netbsd.org/~christos/ptrace32.diff
looks good to me, however the function should be called something like
cpu_mcontext32from64_validate, to make it clear that it's just
cpu_mcontext32_validate with a 64bit structure
and in process_write_regs(), add {}s in the else too
Le 05/07/2019 à 17:22, Michał Górny a écrit :
+#ifdef EXEC_ELF32
+#include
+#endif
+#define PT64_GETXSTATE PT_GETXSTATE
+#define COREDUMP_MACHDEP_LWP_NOTES \
+{ \
+ struct
Le 02/07/2019 à 16:21, J. Hannken-Illjes a écrit :
On 1. Jul 2019, at 20:12, Maxime Villard wrote:
Le 01/07/2019 à 19:40, J. Hannken-Illjes a écrit :
Sometimes kmem_alloc() returns an address below
VM_MIN_KERNEL_ADDRESS, something like
kmem_alloc() -> 0xaba25800a
Le 01/07/2019 à 19:40, J. Hannken-Illjes a écrit :
Sometimes kmem_alloc() returns an address below
VM_MIN_KERNEL_ADDRESS, something like
kmem_alloc() -> 0xaba25800a5a8 with
VM_MIN_KERNEL_ADDRESS 0xad80
It doesn't happen after every reboot and breaks
dtrace which treats
Le 05/06/2019 à 21:26, Kamil Rytarowski a écrit :
On 05.06.2019 08:08, Maxime Villard wrote:
I intend to change the NVMM API in order to reduce the data movements. The
patches are available here [1].
This looks good and it will make the interfaces simpler.
Could we merge the demo example
Le 22/06/2019 à 09:38, Michał Górny a écrit :
Hi,
Attached is the next version of unified patch. I've updated the boolean
logic as requested, and fixed indentations.
Looks good to me. Please don't use ()s when not needed, like
- memset(&(xstate->xs_fxsave), 0,
Le 22/06/2019 à 07:42, Michał Górny a écrit :
On Sat, 2019-06-22 at 07:35 +0200, Maxime Villard wrote:
Le 19/06/2019 à 14:20, Michał Górny a écrit :> On Wed, 2019-06-19 at 06:32
+0200, Maxime Villard wrote:
Can you provide a unified patch so I can review quickly? Sorry for the delay
H
Le 19/06/2019 à 14:20, Michał Górny a écrit :> On Wed, 2019-06-19 at 06:32
+0200, Maxime Villard wrote:
Can you provide a unified patch so I can review quickly? Sorry for the delay
Here you are. Note that the manpage is not updated yet, as I'm waiting
for your comments on the xs_r
Le 25/05/2019 à 08:53, Iain Hibbert a écrit :
On Sat, 25 May 2019, Maxime Villard wrote:
To fix this problem, we need to fix the error handling in ehci_pci_attach(),
so that goto fail does not leave 'sc' in an inconsistent state.
What is the best way to do that? Should I somehow forcibly
Le 09/06/2019 à 09:46, Michał Górny a écrit :
On Sun, 2019-06-09 at 09:08 +0200, Maxime Villard wrote:
Le 07/06/2019 à 20:33, Michał Górny a écrit :
[...]
+int
+process_machdep_doxstate(struct lwp *curl, struct lwp *l, struct uio *uio)
+ /* curl: tracer */
+ /* l
Le 09/06/2019 à 09:33, Michał Górny a écrit :
On Sun, 2019-06-09 at 09:20 +0200, Maxime Villard wrote:
In fact, the whole loop seems wrong: CPUID uses the XCR0_ constants, not the
XSAVE_ constants. Eg HDC is 13 in XCR0_ but 10 in XSAVE_, so you never iterate
over it.
It's intentional. I only
Le 07/06/2019 à 20:33, Michał Górny a écrit :
+#define XSAVE_MAX_COMPONENT XSAVE_Hi16_ZMM
[...]
+size_t x86_xsave_offsets[XSAVE_MAX_COMPONENT] __read_mostly;
+size_t x86_xsave_sizes[XSAVE_MAX_COMPONENT] __read_mostly;
Need +1, but see below
+ /* Get component offsets and sizes for the
Le 07/06/2019 à 20:33, Michał Górny a écrit :
[...]
+int
+process_machdep_doxstate(struct lwp *curl, struct lwp *l, struct uio *uio)
+ /* curl: tracer */
+ /* l:traced */
+{
+ int error;
+ struct xstate r;
+ char *kv;
+
I intend to change the NVMM API in order to reduce the data movements. The
patches are available here [1].
Basically until now the API expected the user to create structures and then
pass them in a libnvmm function. Typically:
/* The structures. */
struct nvmm_machine mach;
Recent Lenovo machines have a Realtek USB 1.1 controller with EHCI. NetBSD
tries to attach it in dev/pci/ehci_pci.c::ehci_pci_attach(), and does goto
fail with "pre-2.0 USB rev".
The thing is, the device remains registered. When I try to shut down the
machine, ehci_pci_detach() gets called and
Le 02/04/2019 à 22:29, Mouse a écrit :
I continue to use pf and not npf because : [...]
However, I must say I'm still a bit confused by this answer (and the
others I've seen). Do you understand that PF is a clear security
risk for your system?
Is it? Do you know MLH's systems enough to know
Le 02/04/2019 à 20:46, MLH a écrit :
I continue to use pf and not npf because :
1) I couldn't get std rulesets to seem to work (been a while though)
2) no port redirection
3) dynamic ruleset use didn't appear to be adequate
4) greylisting (not just email) for custom stuff that I can't see
Le 30/03/2019 à 19:22, Michael van Elst a écrit :
On Sat, Mar 30, 2019 at 04:55:53PM +0100, Maxime Villard wrote:
Of course, if it's really about rototillng things actively in other places
and to limit the amount of work to fix the fallout, it suddenly becomes
reasonable to remove something
Le 30/03/2019 à 20:14, zerous a écrit :
On Sat, Mar 30, 2019 at 05:15:27PM +0100, Maxime Villard wrote:
Kindly find the draft attached along with this mail. I would be glad
to receive feedback on the same.
This sounds really good. However, I have to warn you: this project is
more a userland
Le 30/03/2019 à 16:24, Michael van Elst a écrit :
On Sat, Mar 30, 2019 at 03:11:22PM +0100, Maxime Villard wrote:
The best way forward to drop PF is to actively develop NPF.
... and the best way to actively develop NPF is to stop splitting effort on
three firewalls
So now you stop
Le 29/03/2019 à 12:13, zerous a écrit :
Hi,
I strongly feel like commiting to the project of porting Wine to amd64
on NetBSD. My reasons for this liking include my experience with
BSD/UNIX, C and shell in general. I have always wanted to do systems
engineering which deals with the kernel and
Le 30/03/2019 à 14:34, Michael van Elst a écrit :
On Sat, Mar 30, 2019 at 02:18:29PM +0100, Piotr Meyer wrote:
On Sat, Mar 30, 2019 at 12:59:00PM -, Michael van Elst wrote:
Just to get the facts straight: NPF has a bigger market share *outside*
NetBSD, at least certainly for commercial
Le 30/03/2019 à 11:06, Manuel Bouyer a écrit :
On Sat, Mar 30, 2019 at 06:07:01AM +0100, Maxime Villard wrote:
[...]
If the effort hadn't been split on three firewalls in the last 10 years, but
rather had been focused on only one, don't you think NPF would now be
featureful?
Exactly. If work
Le 30/03/2019 à 10:06, BERTRAND Joël a écrit :
Michael van Elst a écrit :
joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes:
Just a question. I use NPF for a while on NetBSD-8 that provides router
functionalities (over a lot of network interfaces with agr, bridge, vpn
Le 30/03/2019 à 08:51, Michael van Elst a écrit :
On Sat, Mar 30, 2019 at 08:17:44AM +0100, Maxime Villard wrote:
Le 30/03/2019 à 08:07, Michael van Elst a écrit :
m...@m00nbsd.net (Maxime Villard) writes:
If the effort hadn't been split on three firewalls in the last 10 years, but
rather
Le 30/03/2019 à 10:40, Maxime Villard a écrit :
Le 30/03/2019 à 10:06, BERTRAND Joël a écrit :
Michael van Elst a écrit :
joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes:
Just a question. I use NPF for a while on NetBSD-8 that provides router
functionalities (over a lot
Le 30/03/2019 à 08:07, Michael van Elst a écrit :
m...@m00nbsd.net (Maxime Villard) writes:
If the effort hadn't been split on three firewalls in the last 10 years, but
rather had been focused on only one, don't you think NPF would now be
featureful?
Now if the effort of the world hadn't
Le 29/03/2019 à 22:10, Brian Buhrow a écrit :
...
And, prey tell, why is it harder to maintain a modern version
of PF than NPF?
...
It is about the _fourth_ time you ask this question, and for the fourth time
I am going to provide the exact same answer. PF has a legacy design that makes
it
There have been internal discussions about removing PF from NetBSD. Currently,
NetBSD's PF is 11 years old, has received no maintenance, and has accumulated
bugs and vulnerabilities that were fixed upstream but not in NetBSD. The
latest examples are two vulnerabilities recently discovered in PF,
Le 24/03/2019 à 00:41, Thor Lancelot Simon a écrit :
On Sun, Mar 17, 2019 at 05:41:18AM +0800, Paul Goyette wrote:
On Sat, 16 Mar 2019, Maxime Villard wrote:
Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's
COMPAT_LINUX uses COMPAT_OSF1 as dependency (even
Le 16/03/2019 à 22:41, Paul Goyette a écrit :
On Sat, 16 Mar 2019, Maxime Villard wrote:
Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's
COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no proper
dependency in the module), because there are osf1_* calls
Le 16/03/2019 à 22:41, Paul Goyette a écrit :
On Sat, 16 Mar 2019, Maxime Villard wrote:
Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's
COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no proper
dependency in the module), because there are osf1_* calls. Some
Le 16/03/2019 à 20:49, m...@netbsd.org a écrit :
It makes me compelled to delete more of it.
COMPAT_LINUX doesn't work without matching PAGE_SIZE.
What does that mean?
Le 16/03/2019 à 17:44, Dave McGuire a écrit :
On 3/16/19 11:04 AM, Maxime Villard wrote:
I think that what Robert, and others (including me) argument is
actually that things should not be removed, and the reason would be
that this is the core mission, purpose, reason (or whatever you want
Le 16/03/2019 à 17:00, Jason Thorpe a écrit :
On Mar 16, 2019, at 5:09 AM, m...@netbsd.org wrote:
Most likely, COMPAT_ULTRIX and COMPAT_OSF1 have the same type of bugs
that we have seen in compatibility layers elsewhere.
Is it worth his time to test them?
Folks, PLEASE. This is a point I've
Le 16/03/2019 à 16:12, Robert Elz a écrit :
Date:Sat, 16 Mar 2019 14:28:27 +0100
From:Maxime Villard
Message-ID: <17ba7752-793d-d352-09ef-c43676d2f...@m00nbsd.net>
| Ok. So you believe that dead wood should hold back all of the development
| p
Le 16/03/2019 à 14:43, Johnny Billquist a écrit :
On 2019-03-16 14:28, Maxime Villard wrote:
I stated my point clearly and logically, about why certain things have
legitimate reasons to go away, regardless of whether they are compat layers,
or drivers, or something else. Rather than giving
Le 16/03/2019 à 13:53, Robert Elz a écrit :
Whoever is changing them should be fixing all the users of those APIs,
including the ones in the compat code. Consider all the work PaulG
did as part of the kenel module changes recently -- that's an example of
how it should be done. Simply
Le 16/03/2019 à 10:12, Johnny Billquist a écrit :
On 2019-03-16 09:45, Maxime Villard wrote:
Le 16/03/2019 à 06:23, John Nemeth a écrit :
On Mar 15, 10:31pm, Michael Kronsteiner wrote:
}
} i have this discussion today aswell... considering 64/32bit machines.
} if you want ultrix, install
Le 16/03/2019 à 12:17, Robert Elz a écrit :
If there are bug reports that are not being attended to (open PRs),
that's different. Otherwise unmaintained code is simply code that
doesn't need changes (which for emulation of ancient systems is not
a huge surprise - those systems aren't changing
Le 16/03/2019 à 11:26, Johnny Billquist a écrit :
If the answer is that we remove the code, then indeed, the whole webpage is
incorrect, and we should change it to state that we do not try to be
interoperable, implementing many standard APIs, or care about other platforms.
There seems to be
I would like to remove the 'ioff' argument from pool_init() and friends,
documented as 'align_offset' in the man page. This parameter allows the
caller to specify that the alignment given in 'align' is to be applied at
the offset 'ioff' within the buffer.
The two users I could find are:
*
Le 10/03/2019 à 17:39, Maxime Villard a écrit :
There's been more emphasis on the fact that COMPAT_OSF1 should go. Do people
have anything to say about that?
So, no one? I will remove it soon...
Please read _*all*_ the answers, because I've already said that I was fine
with keeping COMPAT_ULTRIX. If someone has been able to even run a full
ULTRIX userland, then it's probably functional enough, and we can keep it
for the time being. Case closed.
Le 10/03/2019 à 13:30, Björn Johannesson a écrit :
>This more likely means that it was an old UFS disk that we do support by
>default in our UFS/FFS code, but I hardly seehow this could be related to
COMPAT_ULTRIX.
What I meant was that it mounted the ULTRIX root disk and proceeded to run
Le 10/03/2019 à 11:25, Björn Johannesson a écrit :
Hello.
COMPAT_ULTRIX (mips) works fine which I recently discovered after shuffling
some disks and NetBSD8 mounted the ULTRIX disk as /
This more likely means that it was an old UFS disk that we do support by
default in our UFS/FFS code, but I
Le 09/03/2019 à 18:58, Jason Thorpe a écrit :
On Mar 9, 2019, at 8:22 AM, Maxime Villard wrote:
New thread, CC'ed to port-pmax@ and port-alpha@, in the continuity of:
https://mail-index.netbsd.org/tech-kern/2019/03/09/msg024754.html
Basically, there were talks about retiring
New thread, CC'ed to port-pmax@ and port-alpha@, in the continuity of:
https://mail-index.netbsd.org/tech-kern/2019/03/09/msg024754.html
Basically, there were talks about retiring COMPAT_ULTRIX and COMPAT_OSF1,
because they are of questionable utility, in addition to being clear dead
Re-reading this thread - which was initially about SVR4 but which diverged in
all directions -, I see there were talks about retiring COMPAT_ULTRIX and
COMPAT_OSF1, because these were of questionable utility, in addition to being
clear dead wood (in terms of use case, commits in these areas, and
Le 29/01/2019 à 05:57, Rin Okuyama a écrit :
Hi,
I'm working on jumbo frame support for axen(4) and mue(4). However,
unfortunately, I find that we do not have proper kernel frameworks
for jumbo frame; there are two problems:
(1)
We do not have external mbuf cluster capable for receiving jumbo
Le 29/01/2019 à 09:42, Jason Thorpe a écrit :
On Jan 29, 2019, at 10:32 AM, Maxime Villard wrote:
- As you said, we have only one cluster size to begin with.
- MEXTMALLOC is here to allocate variable-sized clusters, but it is
really ugly and should be removed. Same for MEXTADD.
- The error
Le 17/01/2019 à 18:05, Michał Górny a écrit :
Hi,
[...]
After a lot of bisecting, and comparing stable 8 branch (which works)
with trunk, I've came to the conclusion that the commit 'Limit the size
of the direct map with a 2MB granularity' [2] is actually causing
the fault. I haven't been
1 - 100 of 392 matches
Mail list logo
