On Fri, Mar 26, 2010 at 01:45:51PM +, Andrew Doran wrote:
> I'm speaking of low level kernel code and driver drivers, areas that to
> date you have had relatively little involvement in.
That's not entirely true, but fair enough.
> I will however consider discussing the points you raise i
On Fri, Mar 26, 2010 at 10:24:02AM +0900, Masao Uebayashi wrote:
> (Honestly, I see benefit to not convincing you; "objection only from
> dholland@" sounds more convincing to me than "no objections".)
Um. I'm sorry you think that. I guess there is no point continuing
this discussion, then. Or mu
On Fri, Mar 26, 2010 at 05:39:03PM +0700, Robert Elz wrote:
> Date:Fri, 26 Mar 2010 14:52:09 +0900
> From:Masao Uebayashi
> Message-ID: <70f62c5e1003252252h6e5ba506xfafceb76f854b...@mail.gmail.com>
>
> | You need to include dependency. You don't need to care the or
> But C include files are a disaster - [...].
> As a user of the things I'd much rather all that just happened
> automatically, when I use fopen() if the compiler needs stdio.h, it
> should just go and get stdio.h - it's absurd to make me explicitly
> say I need it.
That means that either:
(1) Ce
On Thu, Mar 25, 2010 at 03:44:10AM +, David Holland wrote:
> On Fri, Mar 19, 2010 at 02:49:37PM +, Andrew Doran wrote:
> > > I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc.
> > > are never, ever downloaded any more.
> >
> > Right, and these dead ports must be
On Fri Mar 26 2010 at 17:13:18 +0900, Masao Uebayashi wrote:
> > [snip]
>
> Surely this intermediate makefile and directory can go away, eventually.
>
> > [snip]
>
> I see this is toward the direction I'm going too. We can teach
> config(1) to analyze dependency & generate the necessary stub for
Date:Fri, 26 Mar 2010 14:52:09 +0900
From:Masao Uebayashi
Message-ID: <70f62c5e1003252252h6e5ba506xfafceb76f854b...@mail.gmail.com>
| You need to include dependency. You don't need to care the order of
| include lines. This is pretty much same as C headers inclu
I do know you've wasted longer time than me. ;) Actually what I need
are host controller drivers. Just picked up uaudio(4) to learn things
because it looked odder than others. But thanks for the patch.
On Fri, Mar 26, 2010 at 3:14 PM, Antti Kantee wrote:
(snip)
> Index: modules/uaudio/Makefile
On Fri Mar 26 2010 at 13:25:43 +0900, Masao Uebayashi wrote:
> syntax. I spent a whole weekend to read sys/conf/files, ioconf.c, and
> module stubs in sys/dev/usb/uaudio.c. I wasted a whole weekend. I've
This patch should work and make it easier. No, it doesn't solve
dependencies, but gets dev
On Fri, Mar 26, 2010 at 1:55 PM, matthew green wrote:
>
> To manage dependency nicely.
>
> When a module A dpend on B, you write "define A: B", where B has to be
> already "define"'ed in the current syntax. We're managing such
> ordering "by hand" in sys/conf/files. By splitting files &
To manage dependency nicely.
When a module A dpend on B, you write "define A: B", where B has to be
already "define"'ed in the current syntax. We're managing such
ordering "by hand" in sys/conf/files. By splitting files & use
"include", we don't need to manage such a mess b
On Fri, Mar 26, 2010 at 12:41 PM, matthew green wrote:
>
> On Fri, Mar 26, 2010 at 6:49 AM, David Holland
> wrote:
> > On Thu, Mar 25, 2010 at 06:22:17PM +0900, Masao Uebayashi wrote:
> > > > > % grep ':.*,' sys/conf/files | wc -l
> > > > > 86
> > > >
> > > > And? I don't
On Fri, Mar 26, 2010 at 6:49 AM, David Holland
wrote:
> On Thu, Mar 25, 2010 at 06:22:17PM +0900, Masao Uebayashi wrote:
> > > > % grep ':.*,' sys/conf/files | wc -l
> > > > 86
> > >
> > > And? I don't understand your point. There are a lot more than 86
> > > en
On Fri, Mar 26, 2010 at 6:49 AM, David Holland wrote:
> On Thu, Mar 25, 2010 at 06:22:17PM +0900, Masao Uebayashi wrote:
> > > > % grep ':.*,' sys/conf/files | wc -l
> > > > 86
> > >
> > > And? I don't understand your point. There are a lot more than 86
> > > entities in sys/conf/file
On Thu, Mar 25, 2010 at 06:22:17PM +0900, Masao Uebayashi wrote:
> > > % grep ':.*,' sys/conf/files | wc -l
> > > 86
> >
> > And? I don't understand your point. There are a lot more than 86
> > entities in sys/conf/files.
>
> There are many instances where modules have multiple dep
On Thu, Mar 25, 2010 at 09:09:32AM +, David Holland wrote:
> On Thu, Mar 25, 2010 at 12:46:10PM +0900, Masao Uebayashi wrote:
> > % grep ':.*,' sys/conf/files | wc -l
> > 86
>
> And? I don't understand your point. There are a lot more than 86
> entities in sys/conf/files.
There are
On Thu, Mar 25, 2010 at 12:46:10PM +0900, Masao Uebayashi wrote:
> > ?> > ?> It's necessary to be flat to be modular.
> > ?> >
> > ?> > Mm... not strictly. That's only true when there are diamonds in the
> > ?> > dependency graph; otherwise, declaring B inside A just indicates that
> > ?> > B
On Wed, Mar 24, 2010 at 12:57:53PM -0500, Eric Haszlakiewicz wrote:
> On Thu, Mar 25, 2010 at 01:16:02AM +0900, Masao Uebayashi wrote:
> > On Mon, Mar 22, 2010 at 6:14 AM, Sverre Froyen wrote:
> > > Could this be resolved by adding a "get label" ioctl that could be used
> > > on any
> > > device?
On Thu, Mar 25, 2010 at 12:18 PM, David Holland
wrote:
> On Thu, Mar 25, 2010 at 01:14:51AM +0900, Masao Uebayashi wrote:
> > > ?> > (Besides, it's not necessarily as flat as all that, either.)
> > > ?>
> > > ?> It's necessary to be flat to be modular.
> > >
> > > Mm... not strictly. That's o
On Fri, Mar 19, 2010 at 02:49:37PM +, Andrew Doran wrote:
> > I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc.
> > are never, ever downloaded any more.
>
> Right, and these dead ports must be euthanized. The mountain of
> unused device drivers and core kernel cod
On Thu, Mar 25, 2010 at 01:14:51AM +0900, Masao Uebayashi wrote:
> > ?> > (Besides, it's not necessarily as flat as all that, either.)
> > ?>
> > ?> It's necessary to be flat to be modular.
> >
> > Mm... not strictly. That's only true when there are diamonds in the
> > dependency graph; other
>>> Could this be resolved by adding a "get label" ioctl that could be
>>> used on any device?
>> That's part of the plan of "my devfs".
> yuck.
Agreed. For one thing, you can't ioctl anything until you open it,
which is a nontrivial operation for many devices - and closing it when
you're done is
On Thu, Mar 25, 2010 at 01:16:02AM +0900, Masao Uebayashi wrote:
> On Mon, Mar 22, 2010 at 6:14 AM, Sverre Froyen wrote:
> > Could this be resolved by adding a "get label" ioctl that could be used on
> > any
> > device? ?It might return a descriptive string from the device driver /
> > config
>
2010/3/16 Wojciech A. Koszek :
> On Mon, Mar 15, 2010 at 11:50:09PM +0900, Masao Uebayashi wrote:
>> 2010/3/15 Wojciech A. Koszek :
>> > device X
>> >
>> > builds device X staticly into the kernel (and maybe does something
>> > device-specific), while:
>> >
>> > module X
>> >
>> > O
2010/3/16 Wojciech A. Koszek :
> On Tue, Mar 16, 2010 at 06:55:36AM +0900, Masao Uebayashi wrote:
>> On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath wrote:
>> > On Sun, 14 Mar 2010, Wojciech A. Koszek wrote:
>> >
>> >> I was wondering how does Linux/Solaris kernel build system work in terms
>> >
On Mon, Mar 22, 2010 at 6:14 AM, Sverre Froyen wrote:
> On Sat March 20 2010 17:24:07 David Young wrote:
>> On Sat, Mar 20, 2010 at 09:43:21AM -0700, Matt Thomas wrote:
>> > On Mar 20, 2010, at 9:06 AM, Masao Uebayashi wrote:
>> > > On Sun, Mar 21, 2010 at 1:01 AM, Matt Thomas
> wrote:
>> > >> I'
On Fri, Mar 12, 2010 at 4:31 AM, David Holland wrote:
> On Mon, Mar 08, 2010 at 06:33:04PM +0900, Masao Uebayashi wrote:
> > > Well, first of all nothing says you can't read the whole file before
> > > resolving dependencies; there's nothing inherently wrong with
> > >
> > > define foo: bar
>
On Sat March 20 2010 17:24:07 David Young wrote:
> On Sat, Mar 20, 2010 at 09:43:21AM -0700, Matt Thomas wrote:
> > On Mar 20, 2010, at 9:06 AM, Masao Uebayashi wrote:
> > > On Sun, Mar 21, 2010 at 1:01 AM, Matt Thomas
wrote:
> > >> I'm talking about to device. How, as a user, do I know
> > >>
At Fri, 19 Mar 2010 21:23:35 +, Herb Peyerl wrote:
Subject: Re: Dead ports [Re: config(5) break down]
>
> On Fri, Mar 19, 2010 at 05:19:47PM -0400, Thor Lancelot Simon wrote:
> > Have a look at
> > http://www.rmicorp.com/assets/docs/2070SG_XLR_XLS_Product_Selection_Gu
On Fri, Mar 19, 2010 at 05:30:43PM -0400, Thor Lancelot Simon wrote:
> On Fri, Mar 19, 2010 at 09:23:35PM +, Herb Peyerl wrote:
> >
> > Last time I bought a cavium board it was >$5k USD... An Octeon 3850
> > was $700 for 1521 piece part... I didn't think they had anything
> > reasonable down b
On Sat, Mar 20, 2010 at 09:43:21AM -0700, Matt Thomas wrote:
>
> On Mar 20, 2010, at 9:06 AM, Masao Uebayashi wrote:
>
> > On Sun, Mar 21, 2010 at 1:01 AM, Matt Thomas wrote:
> >> I'm talking about to device. How, as a user, do I know what
> >> actual tty does /dev/ttyXX open?
> >
> > If we
On Sun, Mar 21, 2010 at 1:43 AM, Matt Thomas wrote:
>
> On Mar 20, 2010, at 9:06 AM, Masao Uebayashi wrote:
>
>> On Sun, Mar 21, 2010 at 1:01 AM, Matt Thomas wrote:
>>> I'm talking about to device. How, as a user, do I know what
>>> actual tty does /dev/ttyXX open?
>>
>> If we make tty(4) a de
On Mar 20, 2010, at 9:06 AM, Masao Uebayashi wrote:
> On Sun, Mar 21, 2010 at 1:01 AM, Matt Thomas wrote:
>> I'm talking about to device. How, as a user, do I know what
>> actual tty does /dev/ttyXX open?
>
> If we make tty(4) a device, we can lookup its parent by drvctl(8)
> (extend it to r
On Mar 20, 2010, at 8:37 AM, Masao Uebayashi wrote:
> On Sun, Mar 21, 2010 at 12:14 AM, Matt Thomas wrote:
>> Which is fine if you have one type of serial port, but if you have a mix of
>> devices all providing serial ports how do you know what tty is going to what
>> serial port (especially w
On Sun, Mar 21, 2010 at 1:01 AM, Matt Thomas wrote:
> I'm talking about to device. How, as a user, do I know what
> actual tty does /dev/ttyXX open?
If we make tty(4) a device, we can lookup its parent by drvctl(8)
(extend it to return dv_parent).
My question is - is this the only reason why
On Sun, Mar 21, 2010 at 12:14 AM, Matt Thomas wrote:
> Which is fine if you have one type of serial port, but if you have a mix of
> devices all providing serial ports how do you know what tty is going to what
> serial port (especially with multiport serial devices)?
Like puc(4)? It has an arr
On Mar 19, 2010, at 11:21 PM, Masao Uebayashi wrote:
> On Sat, Mar 20, 2010 at 2:42 PM, Masao Uebayashi wrote:
>> audio(4) and tty(4) are very different from my view; audio(4) has the
>> single entry and drivers implement backend. tty(4) is a common
>> interface through which kernel accesses se
On Sat, Mar 20, 2010 at 2:42 PM, Masao Uebayashi wrote:
> audio(4) and tty(4) are very different from my view; audio(4) has the
> single entry and drivers implement backend. tty(4) is a common
> interface through which kernel accesses serial devices (correct me if
> wrong).
>
> I'm very curious w
On Mar 19, 2010, at 1:25 PM, Michael wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> On Mar 19, 2010, at 4:14 PM, David Young wrote:
>
>> Regardless of what we do or do not do with sun2 et cetera, TNF could buy
>> some ARM and MIPS boards for developers. ARM and MIPS b
On Fri, Mar 19, 2010 at 11:49 PM, Andrew Doran wrote:
> Random example:
>
> I had to abandon two paid efforts last year because I ran out
> of time owing to the huge amount of MD code, a lot of which is unused.
> That was TNF's money and my time down the toilet, and we missed out
> on multithreade
On Fri, 19 Mar 2010, Thor Lancelot Simon wrote:
FYI -- and I doubt you could really buy just one of these at this price --
http://avnetexpress.avnet.com/store/em/EMController/Network-Processor/Cavium-Networks/CN5220-500BG729-SCP-Y-G/_/R-8960980/A-8960980/An-0?action=part&catalogId=500201&langId=
On Fri, Mar 19, 2010 at 06:19:27PM -0400, Thor Lancelot Simon wrote:
> FYI -- and I doubt you could really buy just one of these at this price --
> http://avnetexpress.avnet.com/store/em/EMController/Network-Processor/Cavium-Networks/CN5220-500BG729-SCP-Y-G/_/R-8960980/A-8960980/An-0?action=part&ca
On Fri, Mar 19, 2010 at 05:30:43PM -0400, Thor Lancelot Simon wrote:
>
> Cavium and Raza (Now "NetLogic") both have low-core-count parts in
> the way sub-$100 price range. Same basic architecture as the big
> parts (these aren't their cut-down 32-bit parts), just less cores and
> less goodies.
>
On Fri, 19 Mar 2010, Thor Lancelot Simon wrote:
Have a look at
http://www.rmicorp.com/assets/docs/2070SG_XLR_XLS_Product_Selection_Guide_2008-12-16.pdf
specifically at the bottom few rows on the "XLS" chart. You're looking at
parts that have 3 or 4 Gig-E interfaces, tons of useful hardware offl
On Fri, Mar 19, 2010 at 09:23:35PM +, Herb Peyerl wrote:
>
> Last time I bought a cavium board it was >$5k USD... An Octeon 3850
> was $700 for 1521 piece part... I didn't think they had anything
> reasonable down below $500? (and as far as I remember, they already
> had FreeBSD running on th
On Fri, Mar 19, 2010 at 05:19:47PM -0400, Thor Lancelot Simon wrote:
> Have a look at
> http://www.rmicorp.com/assets/docs/2070SG_XLR_XLS_Product_Selection_Guide_2008-12-16.pdf
> specifically at the bottom few rows on the "XLS" chart. You're looking at
> parts that have 3 or 4 Gig-E interfaces, to
On Fri, Mar 19, 2010 at 04:11:08PM -0500, David Young wrote:
>
> I guess that it depends on your application whether these boards are
> "useful" or not, but these places sell inexpensive boards that have
> more-or-less open architecture/documentation:
>
> www.embeddedarm.com
> www.openplug.org
>
On Fri, Mar 19, 2010 at 04:45:21PM -0400, Thor Lancelot Simon wrote:
> On Fri, Mar 19, 2010 at 03:14:57PM -0500, David Young wrote:
> >
> > Regardless of what we do or do not do with sun2 et cetera, TNF could buy
> > some ARM and MIPS boards for developers. ARM and MIPS boards, however,
> > are n
On Fri, Mar 19, 2010 at 03:14:57PM -0500, David Young wrote:
>
> Regardless of what we do or do not do with sun2 et cetera, TNF could buy
> some ARM and MIPS boards for developers. ARM and MIPS boards, however,
> are not so precious as a sun2. In fact, they're abundant, and cheap.
> Nevertheless
der Mouse wrote:
> >>> [...] sun2, pmax, algor, etc. [...]
> >> Right, and these dead ports must be euthanized.
> > For those single developers who still have such machines, as a
> > "hardware replacement" and moral compensation, TNF could buy some new
> > ARM or MIPS board for hacking. Would be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On Mar 19, 2010, at 4:14 PM, David Young wrote:
Regardless of what we do or do not do with sun2 et cetera, TNF could
buy
some ARM and MIPS boards for developers. ARM and MIPS boards,
however,
are not so precious as a sun2. In fact, the
On Fri, Mar 19, 2010 at 07:09:30PM +, Mindaugas Rasiukevicius wrote:
> Andrew Doran wrote:
> > > I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc.
> > > are never, ever downloaded any more.
> >
> > Right, and these dead ports must be euthanized. The mountain of
> > un
> > > I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc.
> > > are never, ever downloaded any more.
> >
> > Right, and these dead ports must be euthanized. The mountain of
> > unused device drivers and core kernel code is a signficant hinderance to
> > people working in the
>>> [...] sun2, pmax, algor, etc. [...]
>> Right, and these dead ports must be euthanized.
> For those single developers who still have such machines, as a
> "hardware replacement" and moral compensation, TNF could buy some new
> ARM or MIPS board for hacking. Would be a win-win case, would not?
Andrew Doran wrote:
> > I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc.
> > are never, ever downloaded any more.
>
> Right, and these dead ports must be euthanized. The mountain of
> unused device drivers and core kernel code is a signficant hinderance to
> people worki
On Thu, Mar 18, 2010 at 08:47:50PM -0400, Thor Lancelot Simon wrote:
> Sigh. Andy did; I didn't. I completely missed that he clearly excluded
> embedded platforms from his original comments.
np.
> I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc.
> are never, ever downl
On Thu, Mar 18, 2010 at 09:07:51AM -0400, Thor Lancelot Simon wrote:
> On Thu, Mar 18, 2010 at 10:20:28AM +, Andrew Doran wrote:
> > On Tue, Mar 16, 2010 at 03:30:15PM -0400, Thor Lancelot Simon wrote:
> >
> > > But bogus justifications involving who downloads what built
> > > binary releases
On Thu, Mar 18, 2010 at 10:20:28AM +, Andrew Doran wrote:
> On Tue, Mar 16, 2010 at 03:30:15PM -0400, Thor Lancelot Simon wrote:
>
> > But bogus justifications involving who downloads what built
> > binary releases from the FTP server are not really helpful to anyone.
>
> Huh??
Did you read
On Tue, Mar 16, 2010 at 03:30:15PM -0400, Thor Lancelot Simon wrote:
> But bogus justifications involving who downloads what built
> binary releases from the FTP server are not really helpful to anyone.
Huh??
On Wed, Mar 17, 2010 at 11:10:59AM -0500, Eric Haszlakiewicz wrote:
> On Tue, Mar 16, 2010 at 08:01:31PM +, David Holland wrote:
> > But recompiling things isn't a complex unautomated procedure, it's a
> > complex automated procedure, and not really that much different from
> > other comple
On Wed, Mar 17, 2010 at 07:48:32PM +0100, Edgar Fu? wrote:
> DH> Nor is it necessarily slow; building a kernel doesn't take any longer
> DH> than booting Vista...
> EH> Maybe on your machine. On mine it's still quite a bit slower than just
> EH> editing a config file.
> Which gives you a tota
DH> Nor is it necessarily slow; building a kernel doesn't take any longer
DH> than booting Vista...
EH> Maybe on your machine. On mine it's still quite a bit slower than just
EH> editing a config file.
Which gives you a totally new "boot from source" option.
On Tue, Mar 16, 2010 at 08:01:31PM +, David Holland wrote:
> But recompiling things isn't a complex unautomated procedure, it's a
> complex automated procedure, and not really that much different from
> other complex automated procedures like binary updates.
The difference here is that a bina
On Tue, 16 Mar 2010 14:11:53 -0400 (EDT)
der Mouse wrote:
> > (What the figures also revealed was that a number of the ports had as
> > close to zero downloads as matters. Which is, to be frank, a red
> > flag for those that are not maintained.)
>
> You appear to think that no downloads equals
Dear participants in this thread,
If you feel the need to share your general opinions about NetBSD or the
direction of development, please continue this on the netbsd-us...@netbsd.org
mailing list.
Please respect the users which have subscribed to the tech- mailing lists to
participate in tech
On Tue, Mar 16, 2010 at 06:50:29PM +0100, Zafer Aydo?an wrote:
> I'm wholeheartedly behind Julio's statement.
> Users should never have to rebuild anything.
Er, why?
Users should never have to perform complex unautomated procedures,
because such procedures can easily be screwed up and recovery
At Tue, 16 Mar 2010 13:35:34 -0400 (EDT), der Mouse
wrote:
Subject: Re: NetBSD & binary [was Re: config(5) break down]
>
> Yes, this excludes the people who don't understand and don't want to.
> To steal a term from marketing, I don't think NetBSD should try to
>
On Tue, Mar 16, 2010 at 03:18:10PM -0400, Greg A. Woods wrote:
>
> Please do not even think about using downloads as a measure of which
> ports are used and how much they are used!
>
> That's a completely invalid measurement of how NetBSD might be used.
No kidding. We'll ship thousands of units
At Tue, 16 Mar 2010 10:22:42 +, Andrew Doran wrote:
Subject: Re: config(5) break down
>
> Correctamundo. 95% of downloads in the week following the release of 5.0
> were for x86. It doesn't say much about embedded but does tell us that
> a very large segment of the use
> (What the figures also revealed was that a number of the ports had as
> close to zero downloads as matters. Which is, to be frank, a red
> flag for those that are not maintained.)
You appear to think that no downloads equals no ousers. I submit that
this is an invalid inference, especially amo
>> Let's instead ask us who, and why, some people do drift over to
>> NetBSD? I would say that a large portion of those are people who
>> for some reason or other have gotten tired of the magical modules,
>> autoconfiguration, and magic tools that manage the system for you,
>> and who wants to hav
2010/3/16 Julio Merino :
> On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi wrote:
>> Let me clarify:
>>
>> - NetBSD is used for many purposes.
>> - The official binary should choose the sane default
>> - FFS_EI enabled by default
>> - XIP would be disabled by default
>> - While leave developer
On Tue, 16 Mar 2010, Martin S. Weber wrote:
> Well, if you tell them, run this script and reboot to configure your
> system for your needs, then most users would sign that. And that's
> all our (cross-)building is. Run a script. Now if the source is not
> properly maintained because someone keeps
could you please use subject lines that somewhat reflect the content
of the discussion please? I was surprised to find a discussion like
this under that subject, or maybe you want to sneak it through? :)
On Tue, Mar 16, 2010 at 11:39:07AM +0100, Johnny Billquist wrote:
> Julio Merino wrote:
> >(..
Julio Merino wrote:
On Mon, Mar 15, 2010 at 11:22 PM, Johnny Billquist wrote:
Julio Merino wrote:
On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi
wrote:
Let me clarify:
- NetBSD is used for many purposes.
- The official binary should choose the sane default
- FFS_EI enabled by default
-
On Tue, Mar 16, 2010 at 09:09:12AM +, Julio Merino wrote:
> I never said that. But last I read, NetBSD has never been targeted
> exclusively to people working on embedded systems.
Correctamundo. 95% of downloads in the week following the release of 5.0
were for x86. It doesn't say much abo
On Tue, Mar 16, 2010 at 06:42:29AM +0100, Wojciech A. Koszek wrote:
> coming from the same "build" and with the same set of critical options.
> Otherwise, if the "struct mutex" changes its size due to #define
> LOCK_DEBUGGING
> in the kernel, you'll going to get a page fault from the module's cod
On Tue, Mar 16, 2010 at 06:22:14AM +0100, Wojciech A. Koszek wrote:
> You mean that you have a solution for:
>
> struct mystruct {
> #ifdef DEBUG_MYSTRUCT
> int line;
> char*file;
> char*func;
> void*another_poin
On Mon, Mar 15, 2010 at 11:22 PM, Johnny Billquist wrote:
> Julio Merino wrote:
>>
>> On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi
>> wrote:
>>>
>>> Let me clarify:
>>>
>>> - NetBSD is used for many purposes.
>>> - The official binary should choose the sane default
>>> - FFS_EI enabled by d
On Tue, Mar 16, 2010 at 05:26:20AM +, David Holland wrote:
> After a fashion. Check how our LOCKDEBUG works. :-/
You mean "crawls"?
Martin
On Tue, Mar 16, 2010 at 06:55:36AM +0900, Masao Uebayashi wrote:
> On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath wrote:
> > On Sun, 14 Mar 2010, Wojciech A. Koszek wrote:
> >
> >> I was wondering how does Linux/Solaris kernel build system work in terms of
> >> opt_*.h files? Do they have some
On Mon, Mar 15, 2010 at 04:57:46PM +, Eduardo Horvath wrote:
> On Sun, 14 Mar 2010, Wojciech A. Koszek wrote:
>
> > I was wondering how does Linux/Solaris kernel build system work in terms of
> > opt_*.h files? Do they have some alternative solutions for #ifdef's based
> > on
> > what has be
On Tue, Mar 16, 2010 at 06:22:14AM +0100, Wojciech A. Koszek wrote:
> You mean that you have a solution for:
>
> struct mystruct {
> #ifdef DEBUG_MYSTRUCT
> int line;
> char*file;
> char*func;
> void*another_poi
On Mon, Mar 15, 2010 at 11:50:09PM +0900, Masao Uebayashi wrote:
> 2010/3/15 Wojciech A. Koszek :
> > device X
> >
> > builds device X staticly into the kernel (and maybe does something
> > device-specific), while:
> >
> > module X
> >
> > Only builds a KLD. I picked "module", since
Julio Merino wrote:
On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi wrote:
Let me clarify:
- NetBSD is used for many purposes.
- The official binary should choose the sane default
- FFS_EI enabled by default
- XIP would be disabled by default
- While leave developers freedom to customize N
On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi wrote:
> Let me clarify:
>
> - NetBSD is used for many purposes.
> - The official binary should choose the sane default
> - FFS_EI enabled by default
> - XIP would be disabled by default
> - While leave developers freedom to customize NetBSD more
On Tue, Mar 16, 2010 at 6:55 AM, Masao Uebayashi wrote:
> And this is what NetBSD should not be, IMO, because
> - one of NetBSD's targets is highly customized embedded purposes
> - let users customize as they want
> - NetBSD is free, unlike QNX.
> - "users are not stupid"
> - but those c
On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath wrote:
> On Sun, 14 Mar 2010, Wojciech A. Koszek wrote:
>
>> I was wondering how does Linux/Solaris kernel build system work in terms of
>> opt_*.h files? Do they have some alternative solutions for #ifdef's based on
>> what has been included into
On Sun, 14 Mar 2010, Wojciech A. Koszek wrote:
> I was wondering how does Linux/Solaris kernel build system work in terms of
> opt_*.h files? Do they have some alternative solutions for #ifdef's based on
> what has been included into the kernel at configuration time?
It's been a while since I po
On Mon, Mar 15, 2010 at 11:50:09PM +0900, Masao Uebayashi wrote:
[...]
> Without looking them, I don't think any infrastructural (== config(1)
You know, saying stuff like "without looking at [this]", or "i haven't
read any of [that]", while honest, is not a very good way of leading a
conversation.
2010/3/15 Wojciech A. Koszek :
> device X
>
> builds device X staticly into the kernel (and maybe does something
> device-specific), while:
>
> module X
>
> Only builds a KLD. I picked "module", since it seems to be more-or-less an
> oposite of:
>
> static X
>
> which could
On Thu, Mar 11, 2010 at 07:31:58PM +, David Holland wrote:
> On Mon, Mar 08, 2010 at 06:33:04PM +0900, Masao Uebayashi wrote:
> > > Well, first of all nothing says you can't read the whole file before
> > > resolving dependencies; there's nothing inherently wrong with
> > >
> > > define fo
On Mon, Mar 08, 2010 at 06:33:04PM +0900, Masao Uebayashi wrote:
> > Well, first of all nothing says you can't read the whole file before
> > resolving dependencies; there's nothing inherently wrong with
> >
> > define foo: bar
> > :
> > define bar: baz
> > :
> >
> > I have no idea i
i don't think we're going to *give up* static kernel configs,
regardless of how far we come modularwise.
.mrg.
On Mon, 8 Mar 2010, Quentin Garnier wrote:
> On Mon, Mar 08, 2010 at 04:43:17PM +, Eduardo Horvath wrote:
> > Allright. I have to ask:
> >
> > If the plan is to go to a dynamically probed system with loadable modules,
> > why keep config around at all? It's only useful for custom kernels.
On Mon, Mar 08, 2010 at 04:43:17PM +, Eduardo Horvath wrote:
> If the plan is to go to a dynamically probed system with loadable modules,
> why keep config around at all? It's only useful for custom kernels. Why
> is it useful to give config a facelift instead of doing away with it
> entir
On Mon, Mar 08, 2010 at 04:43:17PM +, Eduardo Horvath wrote:
> On Fri, 5 Mar 2010, Masao Uebayashi wrote:
>
> > I've found that the difficulty of understanding config(5) is due to its
> > flexibility; it can do one thing in many ways. You can define a collection
> > of sources with define, de
On Fri, 5 Mar 2010, Masao Uebayashi wrote:
> I've found that the difficulty of understanding config(5) is due to its
> flexibility; it can do one thing in many ways. You can define a collection
> of sources with define, defflag, device, defpseudo{,dev}, devfs. OTOH you
> can only write dependenc
> define foo: bar
> :
> define bar: baz
> :
>
> I have no idea if config currently allows this
It doesn't allow, BTW
/src/netbsd/src.TNF/sys/conf/files:289: undefined attribute `scsi_core'
Masao
> Well, first of all nothing says you can't read the whole file before
> resolving dependencies; there's nothing inherently wrong with
>
> define foo: bar
> :
> define bar: baz
> :
>
> I have no idea if config currently allows this but it's not exactly
> difficult to arrange.
I don't think i
1 - 100 of 117 matches
Mail list logo
