Re: freebsd-i386 status update
Tollef Fog Heen wrote:
* Nathan Hawkins
| Hmm. fdisk in util-linux probably isn't usable. It won't build, and I
| doubt it can reasonably be made to. Also, I'm not even sure it can
| create FreeBSD slices and partitions correctly on Linux. I can build
| FreeBSD fdisk and disklabel, but they're really not well suited to
| installers. (FreeBSD doesn't use them.)
It was meant as an example on how to make an udeb, not particularly
util-linux.
Ok. What's the preferred partitioning tool for debian-installer, anyway?
I'd been thinking in terms of working on parted at some point. IIRC, it
already has the needed partition support, and someone started, but
didn't finish UFS support.
| At the moment, installation has to wait. I'm nearly starting over by
| going to glibc. (And the unstable and incomplete state of glibc
| doesn't help. Right now, I can't even make a package of it.) I have
| problems with gcc and binutils also, so getting those issues fixed are
| a higher priority right now.
ok.
Note that this needn't stop netbsd, and a lot of their issues will be
about the same. OpenBSD issues are probably similar, or perhaps weirder.
| That said, I browsed through the CVS tree, and I do have a few comments:
| * Busybox is going to be a lot of work to port to *BSD. Quite possibly
| one of the hardest packages I've seen. 8-(
argh, that's bad. :( Erik, we need busybox for *BSD, how hard do you
think it will be?
I can partially answer that:
* Everything that uses <linux/> or <asm/> won't work, and will require
changes. So find or grep should be fine, but ifconfig would probably
have to be rewritten.
* libbb will need changes. Functions like find_pid_by_name will need to
be replaced.
Best place to start would be deciding:
Should *BSD support be in same file, and use #ifdef, or in different
files, and have the build system compile alternate modules?
Once that's decided, the necessary feature macros need to go into the
build system. Then it'd be a matter of disabling everything that doesn't
compile, and start writing replacements. I can do that for FreeBSD.
| * Anything to do with device detection and network configuration will
| probably be different. At the least, device names will likely be
| different. Ethernet interfaces won't all begin with eth.
| * Almost anything that looks at /proc won't work. It would be a good
| idea to avoid that in code that is intended to be common to all archs.
Progenies, any idea if/when we can have discover which work on *BSD as
well? Any idea how much work it will be? Is it doable at all?
It might be easier in 2.0, if I remember the talk from debconf 2 correctly.
Sure, currently the whole tree is too Linux/i386 centric, but I want
to get away from that as soon as possible.
Best bet there is to identify stuff that depends on non-standardized
kernel interfaces (i.e. /proc or ioctl), or particular hardware
architectures. Disk partitioning is an issue even for linux, since at
least sparc and alpha, IIRC, use BSD disklabels. (Sparc uses Sun's
disklabel format, and alpha does Digital's if you use aboot.) I seem to
recall that IA-64 uses something entirely different, and most likely so
do some of the others.
| * I would suggest processing the lists of udeb's in build/pkg-lists
| with cpp or m4. That would allow you to use #include or whatever m4
| calls it. That way, the list of udeb's for linux archs could use
| #include linux-common, while BSD ports could do something else. Also
| would take care of comments, and allow use of macros for things like
| kernel flavours.
Kernel flavours are already fixed, through a sed line, but we might
want to go with cpp/m4. That is simple to change.
That's about what I was thinking. It's easy, and adds some flexibility
that could become useful later.
---Nathan
Reply to: