I've just committed a better, and more well-tested, version. Should
work correctly now.
Thanks for your patience, and sorry for the breakage.
On Tue, 29 Apr 2025, Paul Goyette wrote:
Thanks for the link to the log. I am investigating.
On Tue, 29 Apr 2025, Thomas Klausner wrote:
On Tue, A
Thanks for the link to the log. I am investigating.
On Tue, 29 Apr 2025, Thomas Klausner wrote:
On Tue, Apr 29, 2025 at 09:08:38AM +, Martin Husemann wrote:
Module Name:src
Committed By: martin
Date: Tue Apr 29 09:08:38 UTC 2025
Modified Files:
src/sys/arch/i386/s
On Tue, Apr 29, 2025 at 09:08:38AM +, Martin Husemann wrote:
> Module Name: src
> Committed By: martin
> Date: Tue Apr 29 09:08:38 UTC 2025
>
> Modified Files:
> src/sys/arch/i386/stand/boot: boot2.c
> src/sys/arch/i386/stand/efiboot: boot.c
>
> Log Message:
> Backout /fi
Hi,
On 2024/09/19 3:33, Andrius V wrote:
On Wed, Sep 18, 2024 at 3:44 AM Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Sep 18 00:44:03 UTC 2024
Modified Files:
src/sys/arch/i386/stand/lib: libi386.h
Log Message:
i386/stand: Remove XMS leftover from
On Wed, Sep 18, 2024 at 3:44 AM Rin Okuyama wrote:
>
> Module Name:src
> Committed By: rin
> Date: Wed Sep 18 00:44:03 UTC 2024
>
> Modified Files:
> src/sys/arch/i386/stand/lib: libi386.h
>
> Log Message:
> i386/stand: Remove XMS leftover from libi386.h, NFC
>
> PR port-i3
On 2023/07/24 16:14, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Mon Jul 24 01:56:59 UTC 2023
Modified Files:
src/sys/arch/i386/stand/efiboot: Makefile.efiboot eficons.c
Added Files:
src/sys/arch/i386/stand/efiboot: eficpufu
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Mon Jul 24 01:56:59 UTC 2023
>
> Modified Files:
> src/sys/arch/i386/stand/efiboot: Makefile.efiboot eficons.c
> Added Files:
> src/sys/arch/i386/stand/efiboot: eficpufunc.c eficpufunc.h
>
> Log Message:
> efi
Emmanuel Dreyfus writes:
> On Thu, Jun 29, 2023 at 08:43:36PM -0400, Greg Troxel wrote:
>> > Primary bootstrap is now able to read a GPT inside RAIDframe.
>> did you also update documentation?
>
> We do not have any documentation specific to primary bootstrap.
> x86/boot(8) domuent the behavior
On Thu, Jun 29, 2023 at 08:43:36PM -0400, Greg Troxel wrote:
> > Primary bootstrap is now able to read a GPT inside RAIDframe.
> did you also update documentation?
We do not have any documentation specific to primary bootstrap.
x86/boot(8) domuent the behavior with no detail about primary
and sec
"Emmanuel Dreyfus" writes:
> Log Message:
> Primary bootstrap is now able to read a GPT inside RAIDframe.
did you also update documentation?
Emmanuel Dreyfus wrote:
> In src/sys/arch/i386/stand/lib/biosdisk.c
> int
> biosdisk_findpartition(int biosdev, daddr_t sector,
>int *partition, const char **part_name)
> {
> (...)
> /* default ot first partition */
> *partition = 0;
> *part_name = N
On Mon, Dec 27, 2021 at 10:54:13PM +1100, Simon Burge wrote:
> If you have a way of preproducing this, I'm happy to have a look.
I recall it now.
In src/sys/arch/i386/stand/efiboot/devopen.c
bios2dev(boot_biosdev, boot_biossector, &devname, &unit,
&partition, NUL
Emmanuel Dreyfus wrote:
> On Mon, Dec 27, 2021 at 01:08:15PM +1100, Simon Burge wrote:
> > What crash did this fix? All the use of part_name by the
> > called functions should check if it is NULL before trying
> > to assign anything to *part_name.
>
> I do not recall the details now, but I had a
On Mon, Dec 27, 2021 at 01:08:15PM +1100, Simon Burge wrote:
> What crash did this fix? All the use of part_name by the
> called functions should check if it is NULL before trying
> to assign anything to *part_name.
I do not recall the details now, but I had a crash because
of this. Please revert
Hi Emmanuel,
"Emmanuel Dreyfus" wrote:
> Module Name: src
> Committed By: manu
> Date: Thu Nov 18 16:18:13 UTC 2021
>
> Modified Files:
>
> src/sys/arch/i386/stand/efiboot: devopen.c
>
> Log Message:
>
> Fix crash because of NULL pointer reference
What crash did this fix? All the
Hi,
Hyper-V Gen.2 VM has only 1024x768 GOP entry.
https://twitter.com/nonakap/status/1227076603470942208
kernel will be booted in text mode. no output to the console.
If execute "gop 0" command before booting a kernel, it works fine.
On Sat, Feb 8, 2020 at 11:35 PM Jared D. McNeill wrote:
>
> M
FYI, my earlier commit for changing the MODULE_HOOK macros also
commented out the hvkvp entry for amd64/GENERIC.
On Fri, 1 Mar 2019, NONAKA Kimihiro wrote:
Module Name:src
Committed By: nonaka
Date: Fri Mar 1 12:23:10 UTC 2019
Modified Files:
src/sys/arch/i386/conf:
On Sun, Jun 17, 2018 at 03:46:39PM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Sun Jun 17 15:46:39 UTC 2018
>
> Modified Files:
> src/sys/arch/i386/include: frameasm.h
>
> Log Message:
> i586 and below don't have this 3-byte nop, so use three 1-byte
In article <20180612032531.ga1...@homeworld.netbsd.org>,
wrote:
>Hi christos!
>
>Could you explain what makes this necessary in the commit messages in
>the future? It isn't very obvious that it fixes a build failure with
>MKREPRO for future netbsd'ers, in case it isn't restructured.
>Ideally in e
On Tue, Jun 12, 2018 at 03:25:31AM +, m...@netbsd.org wrote:
> Hi christos!
>
> Could you explain what makes this necessary in the commit messages in
> the future? It isn't very obvious that it fixes a build failure with
> MKREPRO for future netbsd'ers, in case it isn't restructured.
> Ideally
Hi christos!
Could you explain what makes this necessary in the commit messages in
the future? It isn't very obvious that it fixes a build failure with
MKREPRO for future netbsd'ers, in case it isn't restructured.
Ideally in every commit, so it appears in a 'cvs annotate'.
Thanks.
On Mon, Jun 11
Thanks, Christos.
This should also fix PR/53045 (qemu booting).
On 21 February 2018 at 17:37, Christos Zoulas wrote:
> Module Name:src
> Committed By: christos
> Date: Thu Feb 22 01:37:04 UTC 2018
>
> Modified Files:
> src/sys/arch/i386/stand: Makefile.inc
>
> Log Message
Le 06/07/2017 à 22:23, Manuel Bouyer a écrit :
Module Name:src
Committed By: bouyer
Date: Thu Jul 6 20:23:57 UTC 2017
Modified Files:
src/sys/arch/i386/i386: gdt.c
Log Message:
gdt_size is now in bytes, but the HYPERVISOR_set_gdt() expects a number
of entries and has no
On Mon, Feb 06, 2017 at 10:32:35AM +, NONAKA Kimihiro wrote:
> Module Name: src
> Committed By: nonaka
> Date: Mon Feb 6 10:32:35 UTC 2017
>
> Modified Files:
> src/sys/arch/i386/stand/efiboot: Makefile.efiboot
>
> Log Message:
> Remove unnecessary flag.
Thanks.
Joerg
On Fri, Feb 03, 2017 at 05:24:43PM +, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Fri Feb 3 17:24:43 UTC 2017
>
> Modified Files:
> src/sys/arch/i386/stand/efiboot: Makefile.efiboot
>
> Log Message:
> Fix build with clang.
Instead of disabling the noretu
On Fri, Feb 03, 2017 at 05:24:43PM +, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Fri Feb 3 17:24:43 UTC 2017
>
> Modified Files:
> src/sys/arch/i386/stand/efiboot: Makefile.efiboot
>
> Log Message:
> Fix build with clang.
Nonaka-san, can you comment on
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Sun Jun 5 14:06:31 UTC 2016
>
> Modified Files:
> src/sys/arch/i386/stand/lib: biosdisk.c exec.c
>
> Log Message:
> The bootinfo is refreshed each time the bootloader tries to execute a
> kernel, so there's n
On Tue, May 31, 2016 at 11:39:08AM +0200, Joerg Sonnenberger wrote:
> On Mon, May 30, 2016 at 06:58:52PM -0400, Christos Zoulas wrote:
> > Module Name:src
> > Committed By: christos
> > Date: Mon May 30 22:58:52 UTC 2016
> >
> > Modified Files:
> > src/sys/arch/i386
On Mon, May 30, 2016 at 06:58:52PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Mon May 30 22:58:52 UTC 2016
>
> Modified Files:
> src/sys/arch/i386/i386: cpu_in_cksum.S
>
> Log Message:
> Handle PIC linking for tests
Except this doesn't work b
On Mon, Jan 04, 2016 at 06:33:50PM +1100, matthew green wrote:
> "Christos Zoulas" writes:
> > Module Name:src
> > Committed By: christos
> > Date: Sun Jan 3 20:59:47 UTC 2016
> >
> > Modified Files:
> > src/sys/arch/i386/stand/bootxx: pbr.S
> >
> > Log Message:
>
On Mon, Jan 04, 2016 at 06:33:50PM +1100, matthew green wrote:
> "Christos Zoulas" writes:
> > Module Name:src
> > Committed By: christos
> > Date: Sun Jan 3 20:59:47 UTC 2016
> >
> > Modified Files:
> > src/sys/arch/i386/stand/bootxx: pbr.S
> >
> > Log Message:
>
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Jan 3 20:59:47 UTC 2016
>
> Modified Files:
> src/sys/arch/i386/stand/bootxx: pbr.S
>
> Log Message:
> change 60 to 70 which is the current release. Noticed by Rares Aioanei.
i don't think so we sho
On Jan 18, 8:18pm, "Jonathan A. Kollasch" wrote:
}
} This is a multi-part message in MIME format.
}
} --_--=_1421612287110410
} Content-Disposition: inline
} Content-Transfer-Encoding: 8bit
} Content-Type: text/plain; charset="US-ASCII"
}
} Module Name: src
} Committed By: jakllsch
} Da
On Fri, May 02, 2014 at 09:14:16AM +0100, David Laight wrote:
> I don't think the linker has a global option to make the eh_frame
> section(s) non-loadable - which ought to allow debuggers to use them
> without taking up program memory (for non paged binaries).
Using objcopy -R is another option (
On Fri, May 02, 2014 at 10:22:48AM +0900, Masao Uebayashi wrote:
> Stripping eh_frame using linker script, without adding unusal gcc
> options, looks much simpler as a whole picture to me.
Except that these programs use the default linker script.
So modifing it is difficult.
I don't think the lin
Stripping eh_frame using linker script, without adding unusal gcc
options, looks much simpler as a whole picture to me.
On Fri, May 2, 2014 at 3:37 AM, David Laight wrote:
> Module Name:src
> Committed By: dsl
> Date: Thu May 1 18:37:26 UTC 2014
>
> Modified Files:
> src/
In article <20140408184900.ga2...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tue, Apr 08, 2014 at 11:34:18AM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Apr 8 15:34:18 UTC 2014
>>
>> Modified Files:
>> src/sys/arch/i
On Tue, Apr 08, 2014 at 11:34:18AM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Apr 8 15:34:18 UTC 2014
>
> Modified Files:
> src/sys/arch/i386/stand/lib: Makefile
>
> Log Message:
> make this more attractive (to me).
Except it is wrong. T
In article <20140407234749.ga19...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Mon, Apr 07, 2014 at 05:09:55PM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Mon Apr 7 21:09:55 UTC 2014
>>
>> Modified Files:
>> src/sys/arch/
On Mon, Apr 07, 2014 at 05:09:55PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Mon Apr 7 21:09:55 UTC 2014
>
> Modified Files:
> src/sys/arch/i386/stand/lib: Makefile
>
> Log Message:
> XXX: gcc-4.8 bug. Passes wrong arguments to biosdisk_read
On Thu, Mar 06, 2014 at 12:30:25PM +, NONAKA Kimihiro wrote:
> Module Name: src
> Committed By: nonaka
> Date: Thu Mar 6 12:30:25 UTC 2014
>
> Modified Files:
> src/sys/arch/i386/i386: cpufunc.S
>
> Log Message:
> fix to pass collect memory address to xrstor.
Gah ... :-(
FWI
> In article <20140128065536.gg1...@apb-laptoy.apb.alt.za>,
> Alan Barrett wrote:
> >On Mon, 27 Jan 2014, Christos Zoulas wrote:
> >>Modified Files:
> >>src/sys/arch/i386/include: vmparam.h
> >>
> >>Log Message:
> >>Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up
> >>
In article <20140128141231.ga3...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tue, Jan 28, 2014 at 08:55:37AM +0200, Alan Barrett wrote:
>> On Mon, 27 Jan 2014, Christos Zoulas wrote:
>> >Modified Files:
>> >src/sys/arch/i386/include: vmparam.h
>> >
>> >Log Message:
>> >Cut down MAXDSIZ
On Tue, Jan 28, 2014 at 08:55:37AM +0200, Alan Barrett wrote:
> On Mon, 27 Jan 2014, Christos Zoulas wrote:
> >Modified Files:
> > src/sys/arch/i386/include: vmparam.h
> >
> >Log Message:
> >Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up
> >supplying an out of bounds hi
In article <20140128065536.gg1...@apb-laptoy.apb.alt.za>,
Alan Barrett wrote:
>On Mon, 27 Jan 2014, Christos Zoulas wrote:
>>Modified Files:
>> src/sys/arch/i386/include: vmparam.h
>>
>>Log Message:
>>Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up
>>supplying an out
On Mon, 27 Jan 2014, Christos Zoulas wrote:
Modified Files:
src/sys/arch/i386/include: vmparam.h
Log Message:
Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up
supplying an out of bounds hint for sigcode (c001e000 > bf00). Makes
a.out binaries work again.
Will
On Fri, 22 Nov 2013, Jeff Rizzo wrote:
Modified Files:
src/sys/arch/i386/conf: ALL
Log Message:
Comment out npf for now, as we can't have both NPF and PF in the
same kernel
It used to be possible to have npf and pf in the same kernel. The
kernel I am running now (built a few weeks ag
On 11/23/13 4:50 AM, Marc Balmer wrote:
Zitat von Jeff Rizzo :
Module Name:src
Committed By:riz
Date:Fri Nov 22 18:58:01 UTC 2013
Modified Files:
src/sys/arch/i386/conf: ALL
Log Message:
Comment out npf for now, as we can't have both NPF and PF in the
same kernel - rmind h
Zitat von Jeff Rizzo :
Module Name:src
Committed By: riz
Date: Fri Nov 22 18:58:01 UTC 2013
Modified Files:
src/sys/arch/i386/conf: ALL
Log Message:
Comment out npf for now, as we can't have both NPF and PF in the
same kernel - rmind has said he'll address this eventual
On Oct 23, 2013, at 11:42 AM, Jukka Ruohonen wrote:
> On Wed, Oct 23, 2013 at 10:37:15AM -0700, Paul Goyette wrote:
>> On Wed, 23 Oct 2013, Matt Thomas wrote:
>>
>>> Module Name:src
>>> Committed By: matt
>>> Date: Wed Oct 23 17:26:08 UTC 2013
>>>
>>> Modified Files
On Wed, Oct 23, 2013 at 10:37:15AM -0700, Paul Goyette wrote:
> On Wed, 23 Oct 2013, Matt Thomas wrote:
>
> >Module Name: src
> >Committed By:matt
> >Date:Wed Oct 23 17:26:08 UTC 2013
> >
> >Modified Files:
> > src/sys/arch/i386/conf: GENERIC XEN3_DOM0
> >
> >Log Messag
On Wed, 23 Oct 2013, Matt Thomas wrote:
Module Name:src
Committed By: matt
Date: Wed Oct 23 17:26:08 UTC 2013
Modified Files:
src/sys/arch/i386/conf: GENERIC XEN3_DOM0
Log Message:
Add xhci device
When do we get a xhci(4) man page? :)
-
On Sun, Oct 20, 2013 at 07:49:55PM +0100, David Laight wrote:
> On Sat, Oct 19, 2013 at 08:16:16PM -0400, Christos Zoulas wrote:
> > Module Name:src
> > Committed By: christos
> > Date: Sun Oct 20 00:16:16 UTC 2013
> >
> > Modified Files:
> > src/sys/arch/i386/stand
On Sat, Oct 19, 2013 at 08:16:16PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sun Oct 20 00:16:16 UTC 2013
>
> Modified Files:
> src/sys/arch/i386/stand/pxeboot: pxe_call.S
>
> Log Message:
> Move an instruction above .code16 so that it produc
On Mon, Oct 01, 2012 at 12:48:24AM +, David Holland wrote:
> (Also, what's the recommended usermode API for programs that want to
> do power stuff?)
I don't think we want a single all-encompassing tool for this. At least that
is my opinion, and the general direction to which many things have g
On Mon, Oct 01, 2012 at 07:37:24AM +0100, David Laight wrote:
> The constants from it get used for ACPI power management
But the only thing used for APM in ACPI is APM emulation ;-).
> and for power management on some completely unrelated hardware. Possibly
> they could be moved to a different he
On Mon, Oct 01, 2012 at 12:48:24AM +, David Holland wrote:
> On Sun, Sep 30, 2012 at 08:19:52PM +, David Laight wrote:
> > Unfortunately apmbios.h is used by the world !
>
> How much of it, and what would happen if we removed it entirely?
> (Also, what's the recommended usermode API for p
On Sun, Sep 30, 2012 at 08:19:52PM +, David Laight wrote:
> Unfortunately apmbios.h is used by the world !
How much of it, and what would happen if we removed it entirely?
(Also, what's the recommended usermode API for programs that want to
do power stuff?)
--
David A. Holland
dholl...@netb
On Sat, Apr 07, 2012 at 01:40:42AM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat Apr 7 05:40:42 UTC 2012
>
> Modified Files:
> src/sys/arch/i386/conf: GENERIC
>
> Log Message:
> add apple autodiscovery
That needs to be added to the ALL conf
On Mon, Mar 05, 2012 at 08:01:09AM +0530, Cherry G. Mathew wrote:
> On 5 March 2012 02:14, Manuel Bouyer wrote:
> > Module Name: src
> > Committed By: bouyer
> > Date: Sun Mar 4 20:44:17 UTC 2012
> >
> > Modified Files:
> > src/sys/arch/i386/i386: machdep.c
> >
> > Log Messa
On 5 March 2012 02:14, Manuel Bouyer wrote:
> Module Name: src
> Committed By: bouyer
> Date: Sun Mar 4 20:44:17 UTC 2012
>
> Modified Files:
> src/sys/arch/i386/i386: machdep.c
>
> Log Message:
> Don't try to uvm_page_physload() the tmpgdt page: this always fails because
>
On Fri, Jan 20, 2012 at 12:39:44PM +0100, Matthias Drochner wrote:
>
> m...@eterna.com.au said:
> > alloc/free here for whatever is using a lot of memory would be much
> > better than increasing the minimum each LWP requires.
>
> Agreed. In the ppbattach case, it should be sufficient
> to put the
chris...@astron.com said:
> /.*sub.*,%[er]sp/
very nice
> 18648 80494b55:stbi_gif_load_from_memory+0xd
So this can never have worked on x86, with only 12k stack.
best regards
Matthias
--
m...@eterna.com.au said:
> alloc/free here for whatever is using a lot of memory would be much
> better than increasing the minimum each LWP requires.
Agreed. In the ppbattach case, it should be sufficient
to put the devinfo printf into a separate function, so
that it doesn't stack up when called
> dyo...@pobox.com said:
> > > increased stack use lead to stack overflow on amd64
> > > with a deep PCI hierarchy
> > Tell me more about this.
>
> It was sys/dev/pci/pci.c rev.1.141 which triggered it.
> Stack use must already have been tight, and the additional
> device number array was the las
dyo...@pobox.com said:
> > increased stack use lead to stack overflow on amd64
> > with a deep PCI hierarchy
> Tell me more about this.
It was sys/dev/pci/pci.c rev.1.141 which triggered it.
Stack use must already have been tight, and the additional
device number array was the last straw.
The que
On Wed, Jan 18, 2012 at 11:38:39PM +0100, Matthias Drochner wrote:
>
> dyo...@pobox.com said:
> > was setting pba_sub = 255 causing material problems for someone, or
> > are you concerned that lossage will eventually occur on certain
> > server-class machines?
>
> No, this wasn't causing damage.
dyo...@pobox.com said:
> was setting pba_sub = 255 causing material problems for someone, or
> are you concerned that lossage will eventually occur on certain
> server-class machines?
No, this wasn't causing damage. I was tracking another problem which
was incidentally triggered by another of yo
On Wed, Jan 18, 2012 at 09:34:39PM +, Matthias Drochner wrote:
> Module Name: src
> Committed By: drochner
> Date: Wed Jan 18 21:34:38 UTC 2012
>
> Modified Files:
> src/sys/arch/i386/i386: mainbus.c
>
> Log Message:
> revert previous, the assumption "all buses 1 and up must be
"J. Hannken-Illjes" wrote:
> > Module Name:src
> > Committed By: yamt
> > Date: Mon Oct 31 12:42:53 UTC 2011
> >
> > Modified Files:
> > src/sys/arch/i386/i386: dumpsys.c
> >
> > Log Message:
> > dumpsys_seg: don't overwrite the previous mapping
>
> With this cha
hi,
> On Oct 31, 2011, at 1:42 PM, YAMAMOTO Takashi wrote:
>
>> Module Name: src
>> Committed By:yamt
>> Date:Mon Oct 31 12:42:53 UTC 2011
>>
>> Modified Files:
>> src/sys/arch/i386/i386: dumpsys.c
>>
>> Log Message:
>> dumpsys_seg: don't overwrite the previous mapp
On Oct 31, 2011, at 1:42 PM, YAMAMOTO Takashi wrote:
> Module Name: src
> Committed By: yamt
> Date: Mon Oct 31 12:42:53 UTC 2011
>
> Modified Files:
> src/sys/arch/i386/i386: dumpsys.c
>
> Log Message:
> dumpsys_seg: don't overwrite the previous mapping
With this change in plac
On Mon, Aug 29, 2011 at 02:58:32PM +0200, Marc Balmer wrote:
> Am 29.08.11 14:53, schrieb Jukka Ruohonen:
> > On Mon, Aug 29, 2011 at 02:48:52PM +0200, Marc Balmer wrote:
> >> Am 29.08.11 11:38, schrieb Jukka Ruohonen:
> >>> On Sat, Aug 27, 2011 at 09:28:56AM +, Marc Balmer wrote:
> Module
Am 29.08.11 14:53, schrieb Jukka Ruohonen:
> On Mon, Aug 29, 2011 at 02:48:52PM +0200, Marc Balmer wrote:
>> Am 29.08.11 11:38, schrieb Jukka Ruohonen:
>>> On Sat, Aug 27, 2011 at 09:28:56AM +, Marc Balmer wrote:
Module Name: src
Committed By: mbalmer
Date:
On Mon, Aug 29, 2011 at 02:48:52PM +0200, Marc Balmer wrote:
> Am 29.08.11 11:38, schrieb Jukka Ruohonen:
> > On Sat, Aug 27, 2011 at 09:28:56AM +, Marc Balmer wrote:
> >> Module Name: src
> >> Committed By: mbalmer
> >> Date: Sat Aug 27 09:28:56 UTC 2011
> >>
> >> Modif
Am 29.08.11 11:38, schrieb Jukka Ruohonen:
> On Sat, Aug 27, 2011 at 09:28:56AM +, Marc Balmer wrote:
>> Module Name: src
>> Committed By:mbalmer
>> Date:Sat Aug 27 09:28:56 UTC 2011
>>
>> Modified Files:
>> src/sys/arch/i386/conf: GENERIC
>>
>> Log Message:
>> Enab
On Sat, Aug 27, 2011 at 09:28:56AM +, Marc Balmer wrote:
> Module Name: src
> Committed By: mbalmer
> Date: Sat Aug 27 09:28:56 UTC 2011
>
> Modified Files:
> src/sys/arch/i386/conf: GENERIC
>
> Log Message:
> Enable some gpio devices.
Is onewire(4) really something to be enab
Module Name:src
Committed By: mrg
Date: Mon Aug 22 09:43:08 UTC 2011
Modified Files:
src/sys/arch/i386/stand/boot: Makefile.boot
Log Message:
disable mmx/sse here too. hopefully fixes amd64 /boot issues.
certainly changes the output in ways that gcc 4.1 doesn't.
Confir
On Tue, Aug 09, 2011 at 10:14:08AM +0200, Manuel Bouyer wrote:
> On Tue, Aug 09, 2011 at 10:47:18AM +0300, Jukka Ruohonen wrote:
> > On Tue, Aug 09, 2011 at 09:44:09AM +0200, Alan Barrett wrote:
> > > Whether or not "available as a module" is a good reason for
> > > removing something from GENERIC
On Tue, Aug 09, 2011 at 11:23:57AM +0300, Jukka Ruohonen wrote:
> On Tue, Aug 09, 2011 at 10:18:29AM +0200, Manuel Bouyer wrote:
> > Sorry, but this is just plain stupid. I could as well make so my work
> > won't work in a modular kernel, and we'll have incompatible features.
>
> Of course it will
On Tue, Aug 09, 2011 at 10:18:29AM +0200, Manuel Bouyer wrote:
> Sorry, but this is just plain stupid. I could as well make so my work
> won't work in a modular kernel, and we'll have incompatible features.
Of course it will work in non-modular kernels, but you just have to add it
there manually.
On Tue, Aug 09, 2011 at 11:16:11AM +0300, Jukka Ruohonen wrote:
> On Tue, Aug 09, 2011 at 10:14:08AM +0200, Manuel Bouyer wrote:
> > On Tue, Aug 09, 2011 at 10:47:18AM +0300, Jukka Ruohonen wrote:
> > > On Tue, Aug 09, 2011 at 09:44:09AM +0200, Alan Barrett wrote:
> > > > Whether or not "available
On Tue, Aug 09, 2011 at 10:14:08AM +0200, Manuel Bouyer wrote:
> On Tue, Aug 09, 2011 at 10:47:18AM +0300, Jukka Ruohonen wrote:
> > On Tue, Aug 09, 2011 at 09:44:09AM +0200, Alan Barrett wrote:
> > > Whether or not "available as a module" is a good reason for
> > > removing something from GENERIC
On Tue, Aug 09, 2011 at 10:47:18AM +0300, Jukka Ruohonen wrote:
> On Tue, Aug 09, 2011 at 09:44:09AM +0200, Alan Barrett wrote:
> > Whether or not "available as a module" is a good reason for
> > removing something from GENERIC is a separate topic which I will
> > not consider in this message.
>
On Tue, Aug 09, 2011 at 09:44:09AM +0200, Alan Barrett wrote:
> Whether or not "available as a module" is a good reason for
> removing something from GENERIC is a separate topic which I will
> not consider in this message.
Fortunately, people can vote with their own work; henceforth all drivers
On Mon, 08 Aug 2011, Jared D. McNeill wrote:
Modified Files:
src/sys/arch/i386/conf: GENERIC
Log Message:
remove dtv (available as a module)
If you remove anything from GENERIC on the grounds that it
is available as a module, then please add the same item to
MONOLITHIC, so that MONOL
On Thu, Aug 04, 2011 at 02:45:54PM +, Jonathan A. Kollasch wrote:
> Module Name: src
> Committed By: jakllsch
> Date: Thu Aug 4 14:45:54 UTC 2011
>
> Modified Files:
> src/sys/arch/i386/conf: ALL
>
> Log Message:
> Add coram(4).
Can we get manual pages for these?
- Jukka.
On Sat, May 21, 2011 at 01:01:52PM +0100, David Laight wrote:
> On Fri, May 20, 2011 at 10:29:56PM +, Joerg Sonnenberger wrote:
> >
> > Log Message:
> > Disable integrated assembler for files that use .code16 or .code32 for
> > now
>
> Would it have been better to do this with a level of
On Fri, May 20, 2011 at 10:29:56PM +, Joerg Sonnenberger wrote:
>
> Log Message:
> Disable integrated assembler for files that use .code16 or .code32 for
> now
Would it have been better to do this with a level of indirection?
So that it could be turned off by changing a global variable in
On Sat, Feb 26, 2011 at 06:22:59PM +, Jonathan A. Kollasch wrote:
> Module Name: src
> Committed By: jakllsch
> Date: Sat Feb 26 18:22:59 UTC 2011
>
> Modified Files:
> src/sys/arch/i386/stand/boot: Makefile.boot
>
> Log Message:
> Enable LIBSA_PRINTF_LONGLONG_SUPPORT.
> Useful
On Wed, 23 Feb 2011 12:17:43 +0900, Masao Uebayashi
wrote:
IMHO, for x86, the kernel cannot assume that the bootloader loaded
certain modules, nor can the bootloader expect that kernel XYZ is in
a
specific configuration. They should be agnostic from one another.
I think that TRT here is that
On Sun, Feb 13, 2011 at 04:29:25PM +0100, Jean-Yves Migeon wrote:
> On 13.02.2011 14:42, David Laight wrote:
> > On Sun, Feb 13, 2011 at 04:37:21AM +, Jean-Yves Migeon wrote:
> >> Module Name: src Committed By: jym Date: Sun Feb
> >> 13 04:37:21 UTC
> >> 2011
> >>
>
On Sun, 13 Feb 2011, Jean-Yves Migeon wrote:
Wording seems a bit redundant, so I condensed this into:
Index: man/man9/module.9
===
RCS file: /cvsroot/src/share/man/man9/module.9,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 mo
On 13.02.2011 17:02, Paul Goyette wrote:
> On Sun, 13 Feb 2011, Jean-Yves Migeon wrote:
>
>> ...
>> For order of preference, see module(7):
>>
>>The loader will look first for a built-in module with the specified
>>name that has not been disabled (see module_unload() below). If a
>>bui
On Sun, 13 Feb 2011, Jean-Yves Migeon wrote:
...
For order of preference, see module(7):
The loader will look first for a built-in module with the specified
name that has not been disabled (see module_unload() below). If a
built-in module with that name is not found, the list of module
On 13.02.2011 14:42, David Laight wrote:
> On Sun, Feb 13, 2011 at 04:37:21AM +, Jean-Yves Migeon wrote:
>> Module Name: src Committed By: jym Date: Sun Feb 13
>> 04:37:21 UTC
>> 2011
>>
>> Modified Files: src/sys/arch/i386/conf: GENERIC
>>
>> Log Message: Compile FFS an
On Sun, Feb 13, 2011 at 04:37:21AM +, Jean-Yves Migeon wrote:
> Module Name: src
> Committed By: jym
> Date: Sun Feb 13 04:37:21 UTC 2011
>
> Modified Files:
> src/sys/arch/i386/conf: GENERIC
>
> Log Message:
> Compile FFS and NFS statically (e.g. not modular) for GENERIC. Thes
On Fri, Feb 11, 2011 at 06:30:17AM +, Matthias Scheler wrote:
> > EXEC_ELF32, _SCRIPT # obvious
> > FFS, CD9660, MFS, TMPFS, NFS, EXT2FS
>
> FFS should be compiled into the kernel. But I doubt that somebody uses
> both MFS and TMPFS. I hardly ever use CD9660 or EXT2FS while I use
> NFS
On Fri, Feb 11, 2011 at 12:40:00AM +0100, Jean-Yves Migeon wrote:
>
> BTW, I wonder whether modules shouldn't be part of the kern-GENERIC.tgz
> set. But this is an orthogonal issue.
As is building the modules as part of the kernel build, and having the
kernel build include a kernel.o stage into w
On 11.02.2011 07:30, Matthias Scheler wrote:
> On Fri, Feb 11, 2011 at 05:06:43AM +0100, Jean-Yves Migeon wrote:
>> Indeed, it would be good to have at least some exec formats and
>> file-systems builtin by default in GENERIC:
>>
>> EXEC_ELF32, _SCRIPT # obvious
>> FFS, CD9660, MFS, TMPFS, NFS, EX
1 - 100 of 156 matches
Mail list logo
