Re: [PATCH] 2.5.14 IDE 56

[Richard B. Johnson]

On Tue, 7 May 2002, Padraig Brady wrote:

> Linus Torvalds wrote:
> >  [ First off: any IDE-only thing that doesn't work for SCSI or other disks
> >    doesn't solve a generic problem, so the complaint that some generic
> >    tools might use it is totally invalid. ]
> > 
> > On Tue, 7 May 2002, Anton Altaparmakov wrote:
> > 
> >>Linux's power is exactly that it can be used on anything from a wristwatch
> >>to a huge server and that it is flexible about everything. You are breaking
> >>this flexibility for no apparent reason. (I don't accept "I can't cope with
> >>this so I remove it." as a reason, sorry).
> > 
> > 
> > Run the 57 patch, and complain if something doesn't work.
> > 
> > Linux's power is that we FIX stuff. That we make it the best system
> > possible, and that we don't just whine and argue about things.
> > 
> > 
> >>As the new IDE maintainer so far we have only seen you removing one
> >>feature after the other in the name of cleanup, without adequate or even
> >>any at all(!) replacements,
> > 
> > 
> > Who cares? Have you found _anything_ that Martin removed that was at all
> > worthwhile? I sure haven't.
> > 
> > Guys, you have to realize that the IDE layer has eight YEARS of absolute
> > crap in it. Seriously. It's _never_ been cleaned up before. It has stuff
> > so distasteful that t's scary.
> > 
> > Take it from me: it's a _lot_ easier to add cruft and crap on top of clean
> > code. You can do it yourself if you want to. You don't need a maintainer
> > to add barnacles.
> > 
> > All the information that /proc/ide gave you is basically available in
> > hdparm, and for your dear embedded system it apparently takes up less
> > space by being in user space. So what is the problem?
> 
> Well my "dear" embedded system doesn't have libc :-(
> So 35664 saved in kernel (less on disk), requires 25212
> extra for hdparm + more for static linked uclibc (hope
> it works ;-)). As a side note if this happens hdparm would
> be a requirement for busybox IMHO, anyway getting back on topic...

Link your embeded stuff against a stripped-down shared libc...

-rwxr-xr-x   1 root     root          876 Apr 26 13:08 crt1.o
-rwxr-xr-x   1 root     root       160824 Feb 25 13:30 ld-linux.so.2
-rwxr-xr-x   1 root     root       160824 Apr 30 11:31 ld.so
-rwxr-xr-x   1 root     root      2376745 Feb 25 13:29 libc.so.6
-rwxr-xr-x   1 root     root       368551 Feb 25 13:29 libm.so.6

This does most everything an embedded system needs. You can extract
the objects from a shared object file (copy), remove the ones you
obviously don't need, make a new shared object file and link. Keep
adding objects until you don't have a any more unresolved symbols.

`ld` allows you to link to whatever you need. I put my special
'libc' plus another private shared library in /opt/lib. On the
target machine, /opt/lib is a sym-link to /lib.

LPATH=/opt/lib
ELINK=-rpath-link $(LPATH) \
 -rpath $(LPATH) \
 -L $(LPATH) -m elf_i386 \
 -dynamic-linker \
 $(LPATH)/ld-linux.so.2 \
 $(LPATH)/crt1.o \
 $(LPATH)/crtendS.o \
 $(LPATH)/libc.so.6 \
 $(LPATH)/libm.so.6

program:	program.o
		ld -o program program.o $(ELINK)

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.