Re: New FS driver (and support for a new OS).

[Kurt Skauen]

OKUJI Yoshinori <address@hidden> writes:

> From: Kurt Skauen <address@hidden>
> Subject: New FS driver (and support for a new OS).
> Date: 31 Oct 2000 10:48:30 +0100
> 
> > Hi, all. I have ported GRUB to the AtheOS operating system
> > <http://www.atheos.cx/> (or was it the other way around? I'm not sure :)
> > and written a GRUB filesystem driver for the native AtheOS filesystem.
> > I also modified the kernel to make it MultiBoot compliant and
> > everything works nicely. I can boot AtheOS directly off a native
> > partition using grub. GRUB rules! :)
> 
>   Great. :)
> 
> > My question now is how to get this port into the regular source tree
> > (if possible)? Should I just mail a diff here? Or is there a contact
> > person I should send this requests to? I could not figure it out by
> > looking at the homepage, all I found was pointers to this list :)
> 
>   You came to the right place. If your patch is small enough, send it
> to this list. Otherwise, put it to somewhere we can download. Don't
> forget to write appropriate ChangeLog entries.

It should not be very large, but I think the simplest solution (to me
atleast) will be to put it on www.atheos.cx somewhere and post a
pointer here. I will fix the changelog and make a patch soon.

I'm a bit worryed about some of the makefile changes I did though. In
AtheOS, executables are loaded from 2GB and up. Hence all binaries
have a default load address of 2GB. This gave some problems with
ld/objcopy since when -Ttext was given to "ld" all data and text
segments (stuff needed by the executable at runtime) was moved to the
appropriate addresses, while the symbol-hash, symbol section, reloc
sections and a few other was left at 2GB. Then when trying to make a
flat binary of the file with objcopy the resulting file spanned all
the sections and filled more than 2GB.  Hard to fit in a boot-block :)
The only solution I found to this (other than hacking the
linker-scripts) was to strip away the offending sections with the "-R"
option to objcopy.

The resulting makfile rule:

%: %.exec
        $(OBJCOPY) -O binary -R .hash -R .dynsym -R .dynstr -R .rel.text \
        -R .rel.data -R .rel.got -R .rel.rodata -R .dynamic $< $@

Could this cause problems on some other platforms? Or can it be left
as it is? Or does anyobody know about a better solution to this
problem?

I also had to add a "--gap-fill 0" to the configure script or else
random data in alignment gaps caused the "absolute address" test to
fail.

 
> > I'm also wondering if the filesystem driver must follow the GNU coding
> > style?
> 
>   It should.

So I have to rewrite it?
Anybody who know about a portable code-obfuscator? :)

>   BTW, I think you will also have to send a copyright assignment to
> the FSF. Gordon will describe how to send it.

Why? And what do this imply?
 

-- 
Kurt Skauen. ( http://www.atheos.cx/ )

"There are two kinds of people, those who do the work and those who take
credit. Try to be in the first group, there is less competition there." __
Indira Gandhi