just as a cautionary tale for the goal of moving everything to the dts: I am working with some basic infiniband tools. As part of their goal of making it all portable and easy to build, they use the libtool support tools. So, for a simple command line like this:
/bin/sh ./libtool --mode=link --tag=CC gcc -g -O2 -o src/vendstat src_vendstat-vendstat.o src_vendstat-ibdiag_common.o -lopensm -losmvendor -losmcomp -libmad -libmad -libumad -libcommon gcc -g -O2 -o src/vendstat src_vendstat-vendstat.o src_vendstat-ibdiag_common.o -lopensm -losmvendor -losmcomp -libmad -libumad -libcommon
They need the libtool script, which is wc libtool 7363 26779 212348 libtool
7363 lines. Geez, how long is the program?
The program is part of a set of diagnostic tools, and the bulk of them are about 200 lines long. So, for a 200-line, 5330 character program, we have a 332 character command line and, if that were not enough, a 7363-line, near quarter million character script.
This is a good example of the conservation of complexity. It is always possible, in the name of hiding details, to create a monstrously complex system that no one can understand.
Just FYI.
ron
just as a cautionary tale for the goal of moving everything to the dts:
"Everything"? A device tree should describe the hardware, and nothing more, ideally. Moving other config stuff in there is typically a Bad Bad Idea. There can be exceptions, of course.
<snip libtool horror story>
This is a good example of the conservation of complexity. It is always possible, in the name of hiding details, to create a monstrously complex system that no one can understand.
The device tree is supposed to *expose* the hardware details, and it should reduce complexity. If it doesn't for you, something is going wrong.
Segher
I saw a demonstration of infiniband at one of the Linuxworld expos, and it just seemed over all far too complicated than it needed to be. That's my 2 cents.
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of ron minnich Sent: Tuesday, May 06, 2008 4:58 PM To: Coreboot Subject: [coreboot] an example of bad magic.
just as a cautionary tale for the goal of moving everything to the dts: I am working with some basic infiniband tools. As part of their goal of making it all portable and easy to build, they use the libtool support tools. So, for a simple command line like this:
/bin/sh ./libtool --mode=link --tag=CC gcc -g -O2 -o src/vendstat src_vendstat-vendstat.o src_vendstat-ibdiag_common.o -lopensm -losmvendor -losmcomp -libmad -libmad -libumad -libcommon gcc -g -O2 -o src/vendstat src_vendstat-vendstat.o src_vendstat-ibdiag_common.o -lopensm -losmvendor -losmcomp -libmad -libumad -libcommon
They need the libtool script, which is wc libtool 7363 26779 212348 libtool
7363 lines. Geez, how long is the program?
The program is part of a set of diagnostic tools, and the bulk of them are about 200 lines long. So, for a 200-line, 5330 character program, we have a 332 character command line and, if that were not enough, a 7363-line, near quarter million character script.
This is a good example of the conservation of complexity. It is always possible, in the name of hiding details, to create a monstrously complex system that no one can understand.
Just FYI.
ron
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Tue, May 6, 2008 at 3:37 PM, Joe joe@settoplinux.org wrote:
I saw a demonstration of infiniband at one of the Linuxworld expos, and it just seemed over all far too complicated than it needed to be. That's my 2 cents.
sorry if I implied this was any kind of infiniband issue. It's not. It's a larger issue. The point is that libtool is 7300+ lines of impenetrable shell script, aimed at 'isolating' users from variations in systems. But by being so complicated, it merely replaces a small amount of complexity -- requiring users in some cases to set LIB= -- by a huge amount of complexity. It's an example of what can go wrong when people set out to make life easier with magic.
I'm a bit concerned at recent posts, because there is some flavor of this confusing magic in v2, and i don't want to see it come in again in v3. For example, I think it's ok to have (e.g.) 71 lines of code in stage1.c for the artec, if that saves us huge amounts of complexity in the dts spec, the dtc compiler, and the device tree code. Sometimes it is ok to expose a small amount of complexity if it avoids a huge amount of hidden complexity. Other times, of course, if we can come up with good design that removes complexity completely, that's a good thing.
that's not to say that getting rid of that 71 lines is not a bad idea; but it *might become* a bad idea if it results in 710 lines of really obscure code.
Thanks
ron
On Tue, May 06, 2008 at 04:06:15PM -0700, ron minnich wrote:
that's not to say that getting rid of that 71 lines is not a bad idea; but it *might become* a bad idea if it results in 710 lines of really obscure code.
Excellent point.
//Peter
-
Joe -
Peter Stuge -
ron minnich -
Segher Boessenkool