matthew green writes:
> could this be done with include and "no foo" statement?
> eg, like sys/arch/sparc/conf/INSTALL does.
Maybe, but I'm not sure it will end up working. Right now we don't know
if any of the missing things will be trouble, and even if we do move to
include/no I'd like to do
"Greg Troxel" writes:
> Module Name: src
> Committed By: gdt
> Date: Fri Mar 5 20:30:56 UTC 2021
>
> Modified Files:
> src/sys/arch/amd64/conf: XEN3_DOM0
>
> Log Message:
> XEN3_DOM0: Approach GENERIC
>
> When processed to remove comments, blank lines, normalize whitespace,
> and so
On 04.06.2020 23:41, Andrew Doran wrote:
> On Thu, Jun 04, 2020 at 02:35:17AM +0200, Kamil Rytarowski wrote:
>
>> On 04.06.2020 00:42, Andrew Doran wrote:
>>> On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
>>>
On 03.06.2020 01:49, Andrew Doran wrote:
> On the assembly t
On Thu, Jun 04, 2020 at 02:35:17AM +0200, Kamil Rytarowski wrote:
> On 04.06.2020 00:42, Andrew Doran wrote:
> > On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
> >
> >> On 03.06.2020 01:49, Andrew Doran wrote:
> >>> On the assembly thing recall that recently you expressed a des
On 04.06.2020 00:42, Andrew Doran wrote:
> On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
>
>> On 03.06.2020 01:49, Andrew Doran wrote:
>>> On the assembly thing recall that recently you expressed a desire to remove
>>> all of the amd64 assembly string functions from libc becaus
Maxime,
I read your e-mail carefully and conclude that the best way forward here is
put this one to core@ for a technical decision.
Cheers,
Andrew
On Wed, Jun 03, 2020 at 08:25:32AM +0200, Maxime Villard wrote:
> Le 03/06/2020 ? 01:49, Andrew Doran a ?crit?:
> > On Tue, Jun 02, 2020 at 08:41:53A
On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
> On 03.06.2020 01:49, Andrew Doran wrote:
> > On the assembly thing recall that recently you expressed a desire to remove
> > all of the amd64 assembly string functions from libc because of sanitizers -
> > I invested my time to do
Le 03/06/2020 à 02:03, Kamil Rytarowski a écrit :
On 03.06.2020 01:49, Andrew Doran wrote:
On the assembly thing recall that recently you expressed a desire to remove
all of the amd64 assembly string functions from libc because of sanitizers -
I invested my time to do up a little demo to try and
Le 03/06/2020 à 01:49, Andrew Doran a écrit :
On Tue, Jun 02, 2020 at 08:41:53AM +0200, Maxime Villard wrote:
Le 02/06/2020 ? 00:58, Andrew Doran a ?crit?:
Module Name:src
Committed By: ad
Date: Mon Jun 1 22:58:06 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpu
On 03.06.2020 01:49, Andrew Doran wrote:
> On the assembly thing recall that recently you expressed a desire to remove
> all of the amd64 assembly string functions from libc because of sanitizers -
> I invested my time to do up a little demo to try and show you why that's not
> a good idea:
>
>
On Tue, Jun 02, 2020 at 08:41:53AM +0200, Maxime Villard wrote:
> Le 02/06/2020 ? 00:58, Andrew Doran a ?crit?:
> > Module Name:src
> > Committed By: ad
> > Date: Mon Jun 1 22:58:06 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/amd64/amd64: cpufunc.S
> > s
Le 02/06/2020 à 00:58, Andrew Doran a écrit :
Module Name:src
Committed By: ad
Date: Mon Jun 1 22:58:06 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S
src/sys/arch/amd64/include: frameasm.h
Log Message:
Reported-by: syzbot+6dd5a230d19f0cbc7...@syzk
Ryo ONODERA wrote:
> However I need multiboot support for amd64.
> I am waiting well-tested implementation.
At this point the problems are more about code style and cleaning, as we
have a fix for the boot bugs that has been reported.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.
Hi,
However I need multiboot support for amd64.
I am waiting well-tested implementation.
"Emmanuel Dreyfus" writes:
> Module Name: src
> Committed By: manu
> Date: Thu Jan 9 00:42:24 UTC 2020
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S machdep.c
> src/sys/arch
On Sun, Jan 05, 2020 at 02:43:43PM +0100, Maxime Villard wrote:
> I have now requested to core@ that multiboot in amd64 be reverted entirely.
So far I privilegied working on a fix to the boot problem that was
reported, rather than spending time on a revert. This was not a futile
effort, since at t
Le 05/01/2020 à 13:56, Maxime Villard a écrit :
> Le 05/01/2020 à 02:03, Emmanuel Dreyfus a écrit :
>> On Sat, Jan 04, 2020 at 08:43:16AM +0100, Maxime Villard wrote:
>>> +.section multiboot,"",@note
>>> Why @note? It will be in the .text anyway. Also why no dot in the section
>>> name? That's supp
Le 05/01/2020 à 02:03, Emmanuel Dreyfus a écrit :
> On Sat, Jan 04, 2020 at 08:43:16AM +0100, Maxime Villard wrote:
>> +.section multiboot,"",@note
>> Why @note? It will be in the .text anyway. Also why no dot in the section
>> name? That's supposed to be the naming convention.
>
> The idea is that
On Sat, Jan 04, 2020 at 08:43:16AM +0100, Maxime Villard wrote:
> +.section multiboot,"",@note
> Why @note? It will be in the .text anyway. Also why no dot in the section
> name? That's supposed to be the naming convention.
The idea is that one day if ld gets more reasonable, it could go in
non-l
On Sat, Jan 04, 2020 at 08:43:16AM +0100, Maxime Villard wrote:
> As said repeatedly, the option should be enabled only _after_ the garbage
> has been cleaned up.
This is not easy if you just call it that. To me it looks like Emanuel
is trying very hard to address all technical issues brought up e
Le 04/01/2020 à 03:33, Emmanuel Dreyfus a écrit :
On Tue, Dec 31, 2019 at 09:32:05AM +0100, Maxime Villard wrote:
I think max-page-size=0x1000 is the right thing to do, but someone needs to
verify that the resulting binary is correct and that the resulting in-memory
layout is correct too.
Atta
On Tue, Dec 31, 2019 at 09:32:05AM +0100, Maxime Villard wrote:
> I think max-page-size=0x1000 is the right thing to do, but someone needs to
> verify that the resulting binary is correct and that the resulting in-memory
> layout is correct too.
Attached is an updated patch with this approach. I t
Masanobu SAITOH wrote:
> I have a UEFI boot machine and it also doesn't boot well.
>
> - It hangs after attaching ioapic0, cpu0 or acpi0 (or something else).
>The possibility is about 65%
> - It sometimes panic in acpi_attach(), acpimcfg_probe or something else.
>The possibility is ab
Le 30/12/2019 à 16:15, Emmanuel Dreyfus a écrit :
> On Sat, Dec 28, 2019 at 02:22:21AM +, Emmanuel Dreyfus wrote:
>>> Regardless of whether it is needed in this specific case, cutting the 2MBs
>>> of zero in the binary is wanted. Unfortunately last I looked at this (two
>>> years ago) there wer
On Sat, Dec 28, 2019 at 02:22:21AM +, Emmanuel Dreyfus wrote:
> > Regardless of whether it is needed in this specific case, cutting the 2MBs
> > of zero in the binary is wanted. Unfortunately last I looked at this (two
> > years ago) there were some non-obvious consequences, and it needs to be
On Fri, Dec 27, 2019 at 06:24:07PM +0100, Maxime Villard wrote:
> Now that I'm looking at i386 I see you've indeed made the same nonsensical
> changes there, with all the unnecessary garbage in the code.
Here I assume you refer to the starting at efi_multiboot2_loader, since
most of the other sign
On Fri, Dec 27, 2019 at 06:24:07PM +0100, Maxime Villard wrote:
> .text : AT (ADDR(.text) & 0x0fff)
> {
> + *(.multiboot)
> +
> . = ALIGN(__PAGE_SIZE);
> __text_user_start = . ;
> ...
>
> This guarantees that the structure is at
Le 27/12/2019 à 17:45, Emmanuel Dreyfus a écrit :
> On Fri, Dec 27, 2019 at 09:02:17AM +0100, Maxime Villard wrote:
>> Please stop with the nonsense... In this patch you are making the multiboot
>> header executable, and putting it in a section shared with userland under
>> SVS. Neither should be r
On Fri, Dec 27, 2019 at 09:02:17AM +0100, Maxime Villard wrote:
> Please stop with the nonsense... In this patch you are making the multiboot
> header executable, and putting it in a section shared with userland under
> SVS. Neither should be required; more than that, both are absolutely _not_
> wa
Hi,
Your patch works fine for my laptop too.
Thank you.
Masanobu SAITOH writes:
> On 2019/12/27 1:55, Emmanuel Dreyfus wrote:
>> On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
> After this change, amd64 kernel does not boot on my HP Spectre x360
> 13-inch ae019TU lapt
Le 26/12/2019 à 17:55, Emmanuel Dreyfus a écrit :
> On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
After this change, amd64 kernel does not boot on my HP Spectre x360
13-inch ae019TU laptop with pure UEFI boot mode.
>> I have a UEFI boot machine and it also doesn't boot
On 2019/12/27 1:55, Emmanuel Dreyfus wrote:
> On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
After this change, amd64 kernel does not boot on my HP Spectre x360
13-inch ae019TU laptop with pure UEFI boot mode.
>> I have a UEFI boot machine and it also doesn't boot well.
On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
> >> After this change, amd64 kernel does not boot on my HP Spectre x360
> >> 13-inch ae019TU laptop with pure UEFI boot mode.
> I have a UEFI boot machine and it also doesn't boot well.
Please try the attached patch.
It adds the -
On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
> - It hangs after attaching ioapic0, cpu0 or acpi0 (or something else).
>The possibility is about 65%
What is the backtace? Does it goes through svs_init?
--
Emmanuel Dreyfus
m...@netbsd.org
Sorry for confusing.
My attached patch does not improve my situation.
My mail is mistake. Sorry.
Reverting linker script fixes the kernel boot.
Thank you.
On December 26, 2019 1:23:34 AM GMT+09:00, Emmanuel Dreyfus
wrote:
>On Wed, Dec 25, 2019 at 07:42:47PM +0900, Ryo ONODERA wrote:
>> The at
On Wed, Dec 25, 2019 at 07:42:47PM +0900, Ryo ONODERA wrote:
> The attached patch works for me.
> However I have no idea about the meaning.
It changes the multiboot section from DATA to CODE, which is
odd but perfectly fine. I cannot understand how it can change
the situation, though. Did it reall
Hi,
Sorry I have accidentally reverted kern.ldscript.
With current kern.ldscript, it stalls after cpu0.
Thank you.
Ryo ONODERA writes:
> Hi,
>
> Emmanuel Dreyfus writes:
>
>> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
>>> After this change, amd64 kernel does not boot on my H
Hi,
Emmanuel Dreyfus writes:
> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
>> After this change, amd64 kernel does not boot on my HP Spectre x360
>> 13-inch ae019TU laptop with pure UEFI boot mode.
>
> Hello
>
> Does the attached patch (crafted for port-amd64/54775) fix the
> pr
On 2019/12/25 17:05, Masanobu SAITOH wrote:
> On 2019/12/24 23:47, Emmanuel Dreyfus wrote:
>> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
>>> After this change, amd64 kernel does not boot on my HP Spectre x360
>>> 13-inch ae019TU laptop with pure UEFI boot mode.
>
> I have a UEFI
On 2019/12/24 23:47, Emmanuel Dreyfus wrote:
> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
>> After this change, amd64 kernel does not boot on my HP Spectre x360
>> 13-inch ae019TU laptop with pure UEFI boot mode.
I have a UEFI boot machine and it also doesn't boot well.
- It h
On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
> After this change, amd64 kernel does not boot on my HP Spectre x360
> 13-inch ae019TU laptop with pure UEFI boot mode.
Hello
Does the attached patch (crafted for port-amd64/54775) fix the
problem?
--
Emmanuel Dreyfus
m...@netbsd.org
Hi,
"Emmanuel Dreyfus" writes:
> Module Name: src
> Committed By: manu
> Date: Sun Dec 15 02:56:40 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S
> src/sys/arch/amd64/conf: kern.ldscript
>
> Log Message:
> Restore multiboot 2 header in amd64 kernel
>
> The
On 05.09.2019 14:57, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Thu Sep 5 12:57:30 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/amd64: lock_stubs.S
>
> Log Message:
> Remove unused, and style.
>
>
> To generate a diff of this commit:
> cvs rdiff -
Le 21/08/2019 à 23:47, matthew green a écrit :
"Maxime Villard" writes:
Module Name:src
Committed By: maxv
Date: Wed Aug 21 16:35:10 UTC 2019
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Message:
Switch from printf to panic. These messages were notorious for b
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Wed Aug 21 16:35:10 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S
>
> Log Message:
> Switch from printf to panic. These messages were notorious for being
> unreadable, and at least a clean
On 07.08.2019 08:28, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Wed Aug 7 06:28:03 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC
>
> Log Message:
> Sync with reality.
>
>
Can we enable USER_LDT by default in GENERIC?
> To generate a
In article ,
Maxime Villard wrote:
>
>This isn't correct, with USER_LDT the 32bit LWPs may have non-default segregs,
>besides it is really dumb to mix 32 and 64bit code, part of the reasons why
>I dropped the thing
Yes, it is still missing the check that the compat_netbsd32 function had.
Before
Le 27/06/2019 à 04:00, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Thu Jun 27 02:00:31 UTC 2019
Modified Files:
src/sys/arch/amd64/amd64: machdep.c
Log Message:
Although this is correct, I will let maxv commit it. Still waiting.
To generate a
On Sun, Apr 22, 2018 at 09:09:40PM +0200, Maxime Villard wrote:
> I recently told membership-exec that I would be less outspoken, and more
> convivial, so here's a try:
>
> Le 22/04/2018 à 20:51, Joerg Sonnenberger a écrit :
> > On Sun, Apr 22, 2018 at 12:36:36PM +0200, Maxime Villard wrote:
> > >
I recently told membership-exec that I would be less outspoken, and more
convivial, so here's a try:
Le 22/04/2018 à 20:51, Joerg Sonnenberger a écrit :
On Sun, Apr 22, 2018 at 12:36:36PM +0200, Maxime Villard wrote:
Where are they? I haven't been made aware of any issue related to SVS+clang.
On Sun, Apr 22, 2018 at 12:36:36PM +0200, Maxime Villard wrote:
> Where are they? I haven't been made aware of any issue related to SVS+clang.
Yes, I did make you aware that SVS killed VirtualBox.
Joerg
On 22.04.2018 12:36, Maxime Villard wrote:
> Le 22/04/2018 à 12:32, Kamil Rytarowski a écrit :
>> On 22.04.2018 07:46, Maxime Villard wrote:
>>> Le 22/04/2018 à 01:25, Joerg Sonnenberger a écrit :
Module Name: src
Committed By: joerg
Date: Sat Apr 21 23:25:01 UTC 2018
>>
Le 22/04/2018 à 12:32, Kamil Rytarowski a écrit :
On 22.04.2018 07:46, Maxime Villard wrote:
Le 22/04/2018 à 01:25, Joerg Sonnenberger a écrit :
Module Name:src
Committed By:joerg
Date:Sat Apr 21 23:25:01 UTC 2018
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Mes
On 22.04.2018 07:46, Maxime Villard wrote:
> Le 22/04/2018 à 01:25, Joerg Sonnenberger a écrit :
>> Module Name: src
>> Committed By: joerg
>> Date: Sat Apr 21 23:25:01 UTC 2018
>>
>> Modified Files:
>> src/sys/arch/amd64/amd64: locore.S
>>
>> Log Message:
>> Do not use movq for lo
Le 22/04/2018 à 01:25, Joerg Sonnenberger a écrit :
Module Name:src
Committed By: joerg
Date: Sat Apr 21 23:25:01 UTC 2018
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Message:
Do not use movq for loading arbitrary 64bit immediates. The ISA
restricts it to 32bi
On Tue, Mar 13, 2018 at 06:02:54PM +0100, Maxime Villard wrote:
> Le 11/03/2018 à 22:30, Joerg Sonnenberger a écrit :
> > Haswell, using VTx. It seems to hit a triple fault in db_panic according
> > to the vbox.log.
>
> At which stage of the boot procedure does it happen? Does it happen right
> be
Le 11/03/2018 à 22:30, Joerg Sonnenberger a écrit :
On Sat, Mar 10, 2018 at 06:58:39PM +0100, Maxime Villard wrote:
Le 09/03/2018 à 20:33, Joerg Sonnenberger a écrit :
On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote:
Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit :
On Mon, F
On Sat, Mar 10, 2018 at 06:58:39PM +0100, Maxime Villard wrote:
> Le 09/03/2018 à 20:33, Joerg Sonnenberger a écrit :
> > On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote:
> > > Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit :
> > > > On Mon, Feb 26, 2018 at 05:52:50AM +, Maxim
On Sat, Mar 10, 2018 at 06:58:39PM +0100, Maxime Villard wrote:
> hardware-assisted or not? I use hardware-assisted, 4.x and 5.x.
I guess also the host CPU will matter (at least in virtualbox).
Martin
Le 09/03/2018 à 20:33, Joerg Sonnenberger a écrit :
On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote:
Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit :
On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote:
Module Name:src
Committed By: maxv
Date: Mon F
On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote:
> Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit :
> > On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote:
> > > Module Name: src
> > > Committed By: maxv
> > > Date: Mon Feb 26 05:52:50 UTC 2018
> >
Le 09/03/2018 à 18:36, Maxime Villard a écrit :
Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit :
On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote:
Module Name:src
Committed By:maxv
Date:Mon Feb 26 05:52:50 UTC 2018
Modified Files:
src/sys/arch/amd64/conf: G
Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit :
On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote:
Module Name:src
Committed By: maxv
Date: Mon Feb 26 05:52:50 UTC 2018
Modified Files:
src/sys/arch/amd64/conf: GENERIC
Log Message:
Enable SVS by default.
On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Mon Feb 26 05:52:50 UTC 2018
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC
>
> Log Message:
> Enable SVS by default.
This broke using VirtualBox and I wouldn't
Le 24/02/2018 à 17:30, Christos Zoulas a écrit :
In article <18bc2a5a-f82d-91ba-5e52-b262c907b...@m00nbsd.net>,
Maxime Villard wrote:
Le 24/02/2018 à 11:54, Martin Husemann a écrit :
On Sat, Feb 24, 2018 at 11:37:11AM +0100, Maxime Villard wrote:
If the macro was defined as #if, you would
In article <18bc2a5a-f82d-91ba-5e52-b262c907b...@m00nbsd.net>,
Maxime Villard wrote:
>Le 24/02/2018 à 11:54, Martin Husemann a écrit :
>> On Sat, Feb 24, 2018 at 11:37:11AM +0100, Maxime Villard wrote:
>>> If the macro was defined as #if, you would need to do something like:
>>>
>>> SYSCALL
Le 24/02/2018 à 11:54, Martin Husemann a écrit :
On Sat, Feb 24, 2018 at 11:37:11AM +0100, Maxime Villard wrote:
If the macro was defined as #if, you would need to do something like:
SYSCALL_ENTRY(syscall)
#define SYSCALL_ENTRY_SVS
SYSCALL_ENTRY(syscall_svs)
#und
On Sat, Feb 24, 2018 at 11:37:11AM +0100, Maxime Villard wrote:
> If the macro was defined as #if, you would need to do something like:
>
> SYSCALL_ENTRY(syscall)
> #define SYSCALL_ENTRY_SVS
> SYSCALL_ENTRY(syscall_svs)
> #undef SYSCALL_ENTRY_SVS
>
> Where SYSCALL_ENTRY wo
Le 24/02/2018 à 11:14, Martin Husemann a écrit :
On Fri, Feb 23, 2018 at 08:09:09AM +0100, Maxime Villard wrote:
... And? There is only one place where we use .if instead of #if, because there
is a good reason for doing so.
Which reason is that?
Well, look at the code. We want to control wha
On Fri, Feb 23, 2018 at 08:09:09AM +0100, Maxime Villard wrote:
> ... And? There is only one place where we use .if instead of #if, because
> there
> is a good reason for doing so.
Which reason is that?
Martin
Le 22/02/2018 à 17:31, Christos Zoulas a écrit :
In article <7f4de63c-e782-14e6-5554-9b9d23471...@m00nbsd.net>,
Maxime Villard wrote:
Le 22/02/2018 à 15:54, Christos Zoulas a écrit :
In article <20180222140848.70e95f...@cvs.netbsd.org>,
Martin Husemann wrote:
-=-=-=-=-=-
Module Name:
On Feb 23, 8:09am, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/arch/amd64/amd64
| > The question is do we want to keep using both cpp and assembly macros.
|
| Why wouldn't we? I don't see the problem.
Because it adds complexity.
| ... And? Ther
In article <7f4de63c-e782-14e6-5554-9b9d23471...@m00nbsd.net>,
Maxime Villard wrote:
>Le 22/02/2018 à 15:54, Christos Zoulas a écrit :
>> In article <20180222140848.70e95f...@cvs.netbsd.org>,
>> Martin Husemann wrote:
>>> -=-=-=-=-=-
>>>
>>> Module Name:src
>>> Committed By: mart
Le 22/02/2018 à 15:54, Christos Zoulas a écrit :
In article <20180222140848.70e95f...@cvs.netbsd.org>,
Martin Husemann wrote:
-=-=-=-=-=-
Module Name:src
Committed By: martin
Date: Thu Feb 22 14:08:48 UTC 2018
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Mes
In article <20180222140848.70e95f...@cvs.netbsd.org>,
Martin Husemann wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: martin
>Date: Thu Feb 22 14:08:48 UTC 2018
>
>Modified Files:
> src/sys/arch/amd64/amd64: locore.S
>
>Log Message:
>Protect the SVS part of SYSCALL_ENTRY b
Le 08/12/2017 à 00:11, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Thu Dec 7 23:11:50 UTC 2017
Modified Files:
src/sys/arch/amd64/amd64: netbsd32_machdep.c
src/sys/arch/amd64/conf: files.amd64
Added Files:
src/sys/arch/amd64/amd
On Sat, Dec 02, 2017 at 09:59:02AM +, Maxime Villard wrote:
> Module Name: src
> Committed By:maxv
> Date:Sat Dec 2 09:59:02 UTC 2017
>
> Modified Files:
> src/sys/arch/amd64/conf: ALL
>
> Log Message:
> Remove options that do not exist on amd64.
Compil
> > [...]
> > + * Default pager_map of 16MB is awfully small. There is have plenty
> > + * of VA so use it.
> > [...]
> >
> > It's only in a comment but "...is have..."?
>
> Thanks, fixed.
thanks! i think an earlier version read "we have plenty", but i've
been trying to avoid using "we" in cod
On Mon, Nov 13, 2017 at 11:16:38AM +1100, Geoff Wing wrote:
> On Sunday 2017-11-12 07:24 +1100, matthew green output:
> :Module Name: src
> :Committed By:mrg
> :Date:Sat Nov 11 20:23:49 UTC 2017
> :Modified Files:
> : src/sys/arch/amd64/include: vmparam.h
> :Log Message:
On Sunday 2017-11-12 07:24 +1100, matthew green output:
:Module Name: src
:Committed By: mrg
:Date: Sat Nov 11 20:23:49 UTC 2017
:Modified Files:
: src/sys/arch/amd64/include: vmparam.h
:Log Message:
:bump PAGER_MAP_DEFAULT_SIZE to 512MB. this should allow more
:concurrent IOs to
On 10/20/17 11:08, Manuel Bouyer wrote:
On Fri, Oct 20, 2017 at 07:06:18AM -0300, Jared McNeill wrote:
On Fri, 20 Oct 2017, Manuel Bouyer wrote:
Any reason to not add it to other arches (especially i386) too ?
I wasn't sure it would work everywhere because there are structures used to
talk to
On Fri, Oct 20, 2017 at 07:06:18AM -0300, Jared McNeill wrote:
> On Fri, 20 Oct 2017, Manuel Bouyer wrote:
>
> > Any reason to not add it to other arches (especially i386) too ?
>
> I wasn't sure it would work everywhere because there are structures used to
> talk to the firmware that are defined
On Fri, 20 Oct 2017, Manuel Bouyer wrote:
Any reason to not add it to other arches (especially i386) too ?
I wasn't sure it would work everywhere because there are structures used
to talk to the firmware that are defined (by both the bwfm driver and the
firmware) w/o __packed.
Are you able
On Thu, Oct 19, 2017 at 11:59:56PM +, Jared D. McNeill wrote:
> Module Name: src
> Committed By: jmcneill
> Date: Thu Oct 19 23:59:56 UTC 2017
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC
>
> Log Message:
> add bwfm
Any reason to not add it to other arches (especiall
See PR kern/51597
There is some rtsock stuff that does not get included in the compat
module.
On Sat, 19 Aug 2017, co...@sdf.org wrote:
try to run 7.1 ifconfig on 8.0. without COMPAT_70 in the kernel, it won't run.
Its non-compatibility is probably buried deep within a switch statement for
try to run 7.1 ifconfig on 8.0. without COMPAT_70 in the kernel, it won't run.
Its non-compatibility is probably buried deep within a switch statement for a
generic function.
The only way we can reasonably make it work is:
- lie about what compat is, and build it inot the kernel, which also hurts
On Wed, Aug 16, 2017 at 05:46:29AM +0800, Paul Goyette wrote:
> On Tue, 15 Aug 2017, Martin Husemann wrote:
>
> > On Tue, Aug 15, 2017 at 04:33:19PM +0200, Maxime Villard wrote:
> > > So we agree? Each compat should be independent.
> >
> > Yes.
>
> Well, not totally independent! We have module
On Tue, 15 Aug 2017, Martin Husemann wrote:
On Tue, Aug 15, 2017 at 04:33:19PM +0200, Maxime Villard wrote:
So we agree? Each compat should be independent.
Yes.
Well, not totally independent! We have module dependencies to enable
the use of common code.
It seems to me that
re-implement
On Tue, 15 Aug 2017, Maxime Villard wrote:
Le 15/08/2017 à 14:50, Martin Husemann a écrit :
On Tue, Aug 15, 2017 at 02:48:39PM +0200, Maxime Villard wrote:
Why is it a bad idea re-implement the few compat_xx functions used in
compat_linux? This would eliminate the dependency, and a single modl
Le 15/08/2017 à 16:38, Martin Husemann a écrit :
On Tue, Aug 15, 2017 at 04:33:19PM +0200, Maxime Villard wrote:
So we agree? Each compat should be independent.
Yes.
It seems to me that
re-implementing (copy-paste) a few functions for linux is a step towards
direction, isn't it?
No, it isn
On Tue, Aug 15, 2017 at 04:33:19PM +0200, Maxime Villard wrote:
> So we agree? Each compat should be independent.
Yes.
> It seems to me that
> re-implementing (copy-paste) a few functions for linux is a step towards
> direction, isn't it?
No, it isn't (but it MAY be ok for real trivial ones).
U
Le 15/08/2017 à 15:18, Martin Husemann a écrit :
On Tue, Aug 15, 2017 at 03:05:31PM +0200, Maxime Villard wrote:
This module already exists, and it's modules/compat. The problem, again,
is that this module will register new syscalls, while we only want the
functions to be available. And it's mor
On Tue, Aug 15, 2017 at 03:05:31PM +0200, Maxime Villard wrote:
> This module already exists, and it's modules/compat. The problem, again,
> is that this module will register new syscalls, while we only want the
> functions to be available. And it's more than that: if dynamically loaded,
> this mod
Le 15/08/2017 à 14:50, Martin Husemann a écrit :
On Tue, Aug 15, 2017 at 02:48:39PM +0200, Maxime Villard wrote:
Why is it a bad idea re-implement the few compat_xx functions used in
compat_linux? This would eliminate the dependency, and a single modload
would suffice.
Move them into a common
On Tue, Aug 15, 2017 at 02:48:39PM +0200, Maxime Villard wrote:
> Why is it a bad idea re-implement the few compat_xx functions used in
> compat_linux? This would eliminate the dependency, and a single modload
> would suffice.
Move them into a common module required by all current consumers.
Mart
Le 04/08/2017 à 10:00, matthew green a écrit :
the setup comes from before modules and it allows code sharing
because the old 43 version matches other systems. so there's
a single implementation of this code for a large number of
consumers, and the name of it describes where it comes from.
this
Le 04/08/2017 à 10:00, matthew green a écrit :
Maxime Villard writes:
Yes, I saw that too a few days later when moving the compat_freebsd files and
trying to do a modload. I went "what the hell is this", but didn't do anything.
What I could see, is that many of our compat options are at some po
Maxime Villard writes:
> Yes, I saw that too a few days later when moving the compat_freebsd files and
> trying to do a modload. I went "what the hell is this", but didn't do
> anything.
>
> What I could see, is that many of our compat options are at some point using
> at least one compat_43_* fu
Le 03/08/2017 à 23:32, co...@sdf.org a écrit :
On Fri, Jul 28, 2017 at 04:10:29PM +, Maxime Villard wrote:
Module Name:src
Committed By: maxv
Date: Fri Jul 28 16:10:29 UTC 2017
Modified Files:
src/sys/arch/amd64/conf: GENERIC XEN3_DOM0 XEN3_DOMU
Log Message:
After a
paulg adds:
This is not making GENERIC fail because COMPAT_43 is not really removed
on it.
$ nm /home/fly/amd/sys/arch/amd64/compile/GENERIC/netbsd |grep compat_43
80403485 T compat_43_netbsd32_fstat43
8040371a T compat_43_netbsd32_killpg
80403431 T compat_43_netbsd32_lsta
On Fri, Jul 28, 2017 at 04:10:29PM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Fri Jul 28 16:10:29 UTC 2017
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC XEN3_DOM0 XEN3_DOMU
>
> Log Message:
> After a careful review, and all things consider
1 - 100 of 186 matches
Mail list logo
