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 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
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
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
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
On Sat, 29 Jul 2017, Paul Goyette wrote:
On Fri, 28 Jul 2017, 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
On Fri, 28 Jul 2017, 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 considered, disable compat43 by
defa
On Sat, Nov 26, 2016 at 09:21:17PM +1100, matthew green wrote:
> > Modified Files:
> >src/sys/arch/amd64/conf: GENERIC
> >
> > Log Message:
> > 1.6 was the first amd64 release. (although it didn't really work too well
> > before -5)
>
> dunno what you're talking about. i ran it for m
"David A. Holland" writes:
> Module Name: src
> Committed By: dholland
> Date: Sat Nov 26 01:09:33 UTC 2016
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC
>
> Log Message:
> 1.6 was the first amd64 release. (although it didn't really work too well
> before -5)
dunno what y
will do.
christos
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Aug 7 10:39:59 UTC 2016
>
> Modified Files:
> src/sys/arch/amd64/conf: MODULAR
>
> Log Message:
> Use "-no" and add more cloners.
please bump the config version and the minimum required config versi
On Jan 10, 2:29pm, ryo...@yk.rim.or.jp (Ryo ONODERA) wrote:
-- Subject: Re: CVS commit: src/sys/arch/amd64/conf
| It is not needed.
I've removed it already!
christos
From: Ryo ONODERA , Date: Sun, 10 Jan 2016 13:04:07 +0900
(JST)
> Hi,
>
> From: chris...@zoulas.com (Christos Zoulas), Date: Sat, 9 Jan 2016 23:01:25
> -0500
>
>> On Jan 10, 12:57pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
>> -- Subject: Re: CVS comm
Hi,
From: chris...@zoulas.com (Christos Zoulas), Date: Sat, 9 Jan 2016 23:01:25
-0500
> On Jan 10, 12:57pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> -- Subject: Re: CVS commit: src/sys/arch/amd64/conf
>
> | christos@ wrote:
> |
> | > Modified Files:
> | >
On Jan 10, 12:57pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/amd64/conf
| christos@ wrote:
|
| > Modified Files:
| > src/sys/arch/amd64/conf: GENERIC
| >
| > Log Message:
| > PR/50636: Ryo ONODERA: Add scsibus to vioscsi
|
| &
christos@ wrote:
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC
>
> Log Message:
> PR/50636: Ryo ONODERA: Add scsibus to vioscsi
>> +#mos* at uhub? port ? # Moschip MCS7730/MCS7830/MCS7832 based
>> adapters
What's this one?
>> +scsibus* at vioscsi?
Why the existing
On Sun, Sep 6, 2015 at 4:17 PM, Masao Uebayashi wrote:
> Module Name:src
> Committed By: uebayasi
> Date: Sun Sep 6 07:17:14 UTC 2015
>
> Modified Files:
> src/sys/arch/amd64/conf: Makefile.amd64 files.amd64
>
> Log Message:
> Define MD start code at the top of files.${MAC
On Wed, Oct 15, 2014 at 08:28:31PM +0700, Robert Elz wrote:
> [...]
> | Including "std.ath_hal" means that you pull in ath device code in your
> | kernel.
>
> No it doesn't. All it is is a bunch of option definitions, by themselves,
> those do (or should do) nothing. What's more, I verified
Date:Sun, 12 Oct 2014 00:17:22 +0900
From:Masao Uebayashi
Message-ID:
For what it is worth, this change (below) just "bit" me - I did my first new
builds for a couple of weeks, and my own Dom0 config failed to build
(because even though the standard XEN3_DOM0 got th
I think this can be fixed by providing new selection statements,
"flags" and/or "params", which are meant to enable flags/params, not
options/attributes.
For ath's case, "options ATHHAL_AR5210" means that you want to include
more *.c's for that option. "params ATHHAL_DEBUG" means that you want
to
On Sun, Oct 12, 2014 at 4:35 AM, Manuel Bouyer wrote:
> On Sun, Oct 12, 2014 at 04:23:17AM +0900, Masao Uebayashi wrote:
>> On Sun, Oct 12, 2014 at 3:48 AM, Manuel Bouyer
>> wrote:
>> > On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote:
>> >> On Sun, Oct 12, 2014 at 3:06 AM, Manuel
On Sun, Oct 12, 2014 at 04:23:17AM +0900, Masao Uebayashi wrote:
> On Sun, Oct 12, 2014 at 3:48 AM, Manuel Bouyer wrote:
> > On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote:
> >> On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer
> >> wrote:
> >> > On Sun, Oct 12, 2014 at 12:17:22AM
On Sun, Oct 12, 2014 at 3:48 AM, Manuel Bouyer wrote:
> On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote:
>> On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer
>> wrote:
>> > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote:
>> >> On Sun, Oct 12, 2014 at 12:05 AM, Manue
On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote:
> On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer wrote:
> > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote:
> >> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer
> >> wrote:
> >> > On Sat, Oct 11, 2014 at 09:50:03AM
On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer wrote:
> On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote:
>> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer
>> wrote:
>> > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote:
>> >> Module Name: src
>> >> Committed By:
On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote:
> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer
> wrote:
> > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote:
> >> Module Name: src
> >> Committed By: uebayasi
> >> Date: Sat Oct 11 09:50:03 UTC 2014
> >>
On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer wrote:
> On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote:
>> Module Name: src
>> Committed By: uebayasi
>> Date: Sat Oct 11 09:50:03 UTC 2014
>>
>> Modified Files:
>> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen
>>
>> Log
On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote:
> Module Name: src
> Committed By: uebayasi
> Date: Sat Oct 11 09:50:03 UTC 2014
>
> Modified Files:
> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen
>
> Log Message:
> Don't include std.ath_hal for XEN3_DOMU.
Why ?
We s
In article <20140612192538.GA2882@neva>,
Alexander Nasonov wrote:
>matthew green wrote:
>> this comment probably would be nice if it was with all instances
>> of INET6, not just amd64 GENERIC. it certainly will help me a
>> couple of times a year when i end up forgetting...
>
>I looked at this.
matthew green wrote:
> this comment probably would be nice if it was with all instances
> of INET6, not just amd64 GENERIC. it certainly will help me a
> couple of times a year when i end up forgetting...
I looked at this. There are 138 files in conf directories with both
INET6 and stf in them. I
"Alexander Nasonov" writes:
> Module Name: src
> Committed By: alnsn
> Date: Thu Jun 12 12:13:36 UTC 2014
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC
>
> Log Message:
> Add a comment about disabling INET6. Should fix kern/48901.
this comment probably would be nice if i
Am 15.03.14 20:18, schrieb John Nemeth:
> On Mar 15, 1:50pm, "Jonathan A. Kollasch" wrote:
> }
> } Module Name:src
> } Committed By: jakllsch
> } Date: Sat Mar 15 13:50:01 UTC 2014
> }
> } Modified Files:
> } src/sys/arch/amd64/conf: XEN3_DOMU
> }
> } Log Message
John Nemeth writes:
> On Mar 15, 1:50pm, "Jonathan A. Kollasch" wrote:
> }
> } Module Name:src
> } Committed By: jakllsch
> } Date: Sat Mar 15 13:50:01 UTC 2014
> }
> } Modified Files:
> } src/sys/arch/amd64/conf: XEN3_DOMU
> }
> } Log Message:
> } Enable PCI
John Nemeth writes:
> On Mar 15, 1:50pm, "Jonathan A. Kollasch" wrote:
> }
> } Module Name:src
> } Committed By: jakllsch
> } Date: Sat Mar 15 13:50:01 UTC 2014
> }
> } Modified Files:
> } src/sys/arch/amd64/conf: XEN3_DOMU
> }
> } Log Message:
> } Enable PCI
On Mar 15, 1:50pm, "Jonathan A. Kollasch" wrote:
}
} Module Name: src
} Committed By: jakllsch
} Date: Sat Mar 15 13:50:01 UTC 2014
}
} Modified Files:
} src/sys/arch/amd64/conf: XEN3_DOMU
}
} Log Message:
} Enable PCI support in amd64 XEN3_DOMU config to match i386 XEN3_DOMU con
On Wed, Oct 23, 2013 at 05:22:49PM +, Matt Thomas wrote:
> Module Name: src
> Committed By: matt
> Date: Wed Oct 23 17:22:49 UTC 2013
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC XEN3_DOM0
>
> Log Message:
> Add xhci device
I would like to state at this time that I a
The problem is that i2c.c can be built either because some other driver
needs "i2cbus" or because an instance of the "iic" driver is requested. Only
in the latter case does CFDRIVER_DECL get added to ioconf.c. I think I'll
have to split out the driver specific stuff into a separate file to fix t
On Aug,Monday 8 2011, at 6:13 PM, Jonathan A. Kollasch wrote:
> Module Name: src
> Committed By: jakllsch
> Date: Mon Aug 8 16:13:42 UTC 2011
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC INSTALL
>
> Log Message:
> Finish reverting premature modularization of amd64 kern
On Mon, Aug 08, 2011 at 04:13:42PM +, Jonathan A. Kollasch wrote:
> Module Name: src
> Committed By: jakllsch
> Date: Mon Aug 8 16:13:42 UTC 2011
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC INSTALL
>
> Log Message:
> Finish reverting premature modularization of amd6
On Mon, 21 Feb 2011 08:00:10 +, David Holland
wrote:
> Hmm -- adding a comment telling that the feature is experimental?
Right now some of the things commented out in amd64 GENERIC are
labeled experimental. Some of them are labeled "built as a module".
Most of them aren't labeled at all. I
On Mon, Feb 21, 2011 at 12:20:14AM +0100, Jean-Yves Migeon wrote:
> On 20.02.2011 22:58, David Holland wrote:
> > 1. Traditionally, whether a driver/fs/option/whatever is listed in
> > GENERIC is an indicator of how stable it's believed to be: entities
> > that are missing are assumed not to wo
On Sun, Feb 20, 2011 at 09:58:44PM +, David Holland wrote:
> years without being solved. In fact, in general all such discussions
> have been shouted down by module advocates insisting without evidence
> that no such problems exist -- this is why these problems remain
> unsolved and have been m
On 20.02.2011 22:58, David Holland wrote:
> 1. Traditionally, whether a driver/fs/option/whatever is listed in
> GENERIC is an indicator of how stable it's believed to be: entities
> that are missing are assumed not to work at all, entities that are
> commented out are assumed not to be stable, and
On Sat, Feb 19, 2011 at 11:33:08AM +0200, Adam Hamsik wrote:
> > Are you going to add a MONOLITHIC kernel to match i386?
>
> I object against such change so I hope that we are not going to
> repeat such move.
I object to *not* having a standard MONOLITHIC config for the
following reasons:
1.
On Sun, Feb 20, 2011 at 06:25:06PM +0200, Antti Kantee wrote:
> On Sun Feb 20 2011 at 17:15:57 +0100, Jean-Yves Migeon wrote:
> > => 1.3MiB. So, a total of 1.3M + 700k = 2MiB. Still missing 1.5MiB.
> > MODULAR options seems to consume ~70kiB , so I would assume that the
> > rest is due to PIC mode
On Sun Feb 20 2011 at 17:15:57 +0100, Jean-Yves Migeon wrote:
> => 1.3MiB. So, a total of 1.3M + 700k = 2MiB. Still missing 1.5MiB.
> MODULAR options seems to consume ~70kiB , so I would assume that the
> rest is due to PIC mode and ELF headers... ?
Dunno where the space is going, but it's certain
On 20.02.2011 15:45, matthew green wrote:
>> Have you measured how much modules supposedly increase the size compared to
>> compiling things directly to the kernel? This seems like a rather silly point
>> to me (without numbers, at least).
>
> well, i dunno about others but i've found that the old
On Sun, Feb 20, 2011 at 07:19:03AM -0800, Paul Goyette wrote:
> "...ignoring [the old modules] problem ..."
>
> A _single_ instance of modules on amd64 occupies > 11MB
>
> # du -sk dest/amd64/stand/amd64/5.99.46/
> 11404 dest/amd64/stand/amd64/5.99.46/
> #
>
> That's nearly a
On Mon, 21 Feb 2011, matthew green wrote:
well, i dunno about others but i've found that the old modules
lying around tends to fill up space pretty quickly, but ignoring
that problem and looking at recent i386 builds, i see that the
MONOLITHIC kernel set is only 440kb larger than GENERIC, yet the
On Sun Feb 20 2011 at 07:19:03 -0800, Paul Goyette wrote:
> On Sun, 20 Feb 2011, Jukka Ruohonen wrote:
>
> >On Mon, Feb 21, 2011 at 01:45:01AM +1100, matthew green wrote:
> >>well, i dunno about others but i've found that the old modules
> >>lying around tends to fill up space pretty quickly, but
On Sun, 20 Feb 2011, Jukka Ruohonen wrote:
On Mon, Feb 21, 2011 at 01:45:01AM +1100, matthew green wrote:
well, i dunno about others but i've found that the old modules
lying around tends to fill up space pretty quickly, but ignoring
that problem and looking at recent i386 builds, i see that th
On Mon, Feb 21, 2011 at 01:45:01AM +1100, matthew green wrote:
> well, i dunno about others but i've found that the old modules
> lying around tends to fill up space pretty quickly, but ignoring
> that problem and looking at recent i386 builds, i see that the
> MONOLITHIC kernel set is only 440kb l
> On Sat, Feb 19, 2011 at 05:13:58PM +0100, Matthias Drochner wrote:
> > 2. I don't want tons of modules which I'll never need installed
> >into my root file system. As it was common in good old times (tm),
> >my root filesystems are as small as possible. Now, with modules
> >being add
On 2/19/2011 8:13 AM, Matthias Drochner wrote:
I think before modular kernels are forced onto the masses,
at least 2 design problems should be fixed:
1. Autoloading needs to be done differently: The kernel doesn't
have the smarts to know which module is needed in which situation,
and ther
On 19.02.2011 17:13, Matthias Drochner wrote:
>
> jeanyves.mig...@free.fr said:
>> I can't see why MONOLITHIC is needed in the first place
>
> I think before modular kernels are forced onto the masses,
> at least 2 design problems should be fixed:
> 1. Autoloading needs to be done differently: Th
jruoho...@iki.fi said:
> Have you measured how much modules supposedly increase the size
> compared to compiling things directly to the kernel? This seems like a
> rather silly point to me (without numbers, at least).
The difference is that I can control what is built into my
kernel, but I can't
On Sat, Feb 19, 2011 at 05:13:58PM +0100, Matthias Drochner wrote:
> 2. I don't want tons of modules which I'll never need installed
>into my root file system. As it was common in good old times (tm),
>my root filesystems are as small as possible. Now, with modules
>being added to the b
jeanyves.mig...@free.fr said:
> I can't see why MONOLITHIC is needed in the first place
I think before modular kernels are forced onto the masses,
at least 2 design problems should be fixed:
1. Autoloading needs to be done differently: The kernel doesn't
have the smarts to know which module is
On 19.02.2011 10:27, Bernd Ernesti wrote:
> On Wed, Feb 16, 2011 at 03:16:58AM +, Jean-Yves Migeon wrote:
>> Module Name: src
>> Committed By:jym
>> Date:Wed Feb 16 03:16:58 UTC 2011
>>
>> Modified Files:
>> src/sys/arch/amd64/conf: GENERIC INSTALL
>>
>> Log Message
On Feb,Saturday 19 2011, at 11:27 AM, Bernd Ernesti wrote:
> On Wed, Feb 16, 2011 at 03:16:58AM +, Jean-Yves Migeon wrote:
>> Module Name: src
>> Committed By:jym
>> Date:Wed Feb 16 03:16:58 UTC 2011
>>
>> Modified Files:
>> src/sys/arch/amd64/conf: GENERIC INSTA
On Wed, Feb 16, 2011 at 03:16:58AM +, Jean-Yves Migeon wrote:
> Module Name: src
> Committed By: jym
> Date: Wed Feb 16 03:16:58 UTC 2011
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC INSTALL
>
> Log Message:
> Build certain file-systems and options(7) as module(7). 32
90 matches
Mail list logo
