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 much of
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
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
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 po...@cs.hut.fi wrote:
(snip)
Index:
Date:Fri, 26 Mar 2010 14:52:09 +0900
From:Masao Uebayashi uebay...@gmail.com
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
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 many
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 dependencies.
On Fri, Mar 26, 2010 at 12:41 PM, matthew green m...@eterna.com.au wrote:
On Fri, Mar 26, 2010 at 6:49 AM, David Holland dholland-t...@netbsd.org
wrote:
On Thu, Mar 25, 2010 at 06:22:17PM +0900, Masao Uebayashi wrote:
% grep ':.*,' sys/conf/files | wc -l
86
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 by hand.
On Fri, Mar 12, 2010 at 4:31 AM, David Holland dholland-t...@netbsd.org 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
2010/3/16 Wojciech A. Koszek wkos...@freebsd.org:
On Tue, Mar 16, 2010 at 06:55:36AM +0900, Masao Uebayashi wrote:
On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath e...@netbsd.org wrote:
On Sun, 14 Mar 2010, Wojciech A. Koszek wrote:
I was wondering how does Linux/Solaris kernel build
2010/3/16 Wojciech A. Koszek wkos...@freebsd.org:
On Mon, Mar 15, 2010 at 11:50:09PM +0900, Masao Uebayashi wrote:
2010/3/15 Wojciech A. Koszek wkos...@freebsd.org:
device X
builds device X staticly into the kernel (and maybe does something
device-specific), while:
On Thu, Mar 25, 2010 at 01:16:02AM +0900, Masao Uebayashi wrote:
On Mon, Mar 22, 2010 at 6:14 AM, Sverre Froyen sve...@viewmark.com 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 /
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 a
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; otherwise, declaring
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 code is a
On Thu, Mar 25, 2010 at 12:18 PM, David Holland
dholland-t...@netbsd.org 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.
On Sat, Mar 20, 2010 at 2:42 PM, Masao Uebayashi uebay...@gmail.com 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
On Sun, Mar 21, 2010 at 1:01 AM, Matt Thomas m...@3am-software.com wrote:
I'm talking about maj, min 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 -
On Mar 20, 2010, at 8:37 AM, Masao Uebayashi wrote:
On Sun, Mar 21, 2010 at 12:14 AM, Matt Thomas m...@3am-software.com 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
On Sun, Mar 21, 2010 at 1:43 AM, Matt Thomas m...@3am-software.com wrote:
On Mar 20, 2010, at 9:06 AM, Masao Uebayashi wrote:
On Sun, Mar 21, 2010 at 1:01 AM, Matt Thomas m...@3am-software.com wrote:
I'm talking about maj, min to device. How, as a user, do I know what
actual tty does
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 m...@3am-software.com wrote:
I'm talking about maj, min to device. How, as a user, do I know what
actual tty does /dev/ttyXX
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 below
At Fri, 19 Mar 2010 21:23:35 +, Herb Peyerl hpey...@beer.org 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_Guide_2008-12-16
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
Andrew Doran a...@netbsd.org 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
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 kernel.
-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,
der Mouse mo...@rodents-montreal.org 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
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,
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 not so
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, tons of
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 the
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.
Even
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 --
On Fri, 19 Mar 2010, Thor Lancelot Simon wrote:
FYI -- and I doubt you could really buy just one of these at this price --
On Fri, Mar 19, 2010 at 11:49 PM, Andrew Doran a...@netbsd.org 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
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 boards,
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 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 what I
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 from the
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 binary
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 complex
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: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_pointer;
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 code with
Julio Merino wrote:
On Mon, Mar 15, 2010 at 11:22 PM, Johnny Billquist b...@softjar.se wrote:
Julio Merino wrote:
On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi uebay...@gmail.com
wrote:
Let me clarify:
- NetBSD is used for many purposes.
- The official binary should choose the sane
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:
(...)
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
2010/3/16 Julio Merino j...@netbsd.org:
On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi uebay...@gmail.com 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
-
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 have better
At Tue, 16 Mar 2010 10:22:42 +, Andrew Doran a...@netbsd.org 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 user
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 of
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
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
2010/3/15 Wojciech A. Koszek wkos...@freebsd.org:
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
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.
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
On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath e...@netbsd.org 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
On Tue, Mar 16, 2010 at 6:55 AM, Masao Uebayashi uebay...@gmail.com 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
-
On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi uebay...@gmail.com 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
Julio Merino wrote:
On Mon, Mar 15, 2010 at 10:08 PM, Masao Uebayashi uebay...@gmail.com 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
On Tue, Mar 16, 2010 at 06:55:36AM +0900, Masao Uebayashi wrote:
On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath e...@netbsd.org 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
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 foo: bar
That line of reasoning only makes sense if splitting things into
multiple files provides some kind of scoping, or encapsulation, or
other form of abstraction.
One *.conf matches one module. We'll always build modules as single object
like intermediate *.a in userland. Expose only necessary
On Mon Mar 08 2010 at 07:09:07 +, David Holland wrote:
Meanwhile, I think trying to wipe out all the boolean dependency logic
in favor of a big graph of modules and submodules is also likely to
make a mess. What happens to e.g.
fileufs/ffs/ffs_bswap.c (ffs | mfs) ffs_ei
On Mon, Mar 08, 2010 at 10:53:16AM +0200, Antti Kantee wrote:
(FFS_EI isn't the only such option either, it's just one I happen to
have already banged heads with.)
This one is easy, no need to make it difficult.
Sure, but as I said it was just an example; what about the next one?
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
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 dependency
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, defflag,
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
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. Why
On Fri, Mar 05, 2010 at 01:14:50AM +0900, Masao Uebayashi wrote:
Perhaps a first step would be using config(1) and files.* to generate
the module makefiles instead of maintaining them by hand...
cube@ said he did this part long time ago. The thing is that only
fixing these tools
config(5) has 4 ways to define a collection of sources:
initialization interface dependency
configurable
device autoconf(9) bdev/cdev y y
defpseudodevxxxattach bdev/cdev n y
defpseudo inet
:
defpseudo gif
file if_gif.c gif
Should have been read as:
defpseudo inet
:
defpseudo gif: inet ---
file if_gif.c gif
On Wed, Mar 03, 2010 at 03:26:20AM +0900, Masao Uebayashi wrote:
I want to slowly start breaking down config(5) files
(sys/conf/files, sys/**/files.*) into small pieces. The goal is to
clarify ownership of files; lines like file aaa.c bbb | ccc are
to be changed into file aaa.c
76 matches
Mail list logo
