Re: Debian for Linux/68k?
>>>>> "Bruce" == Bruce Perens <bruce@Pixar.com> writes:
Bruce> jdassen@WI.LeidenUniv.NL said:
>> Yes. Furthermore, different architectures may need different
>> patches
Bruce> Offhand, the architecture-specific areas I can think of
Bruce> are:
Bruce> 1. Lots of kernel issues - startup, vm, interrupts,
Bruce> device handling.
This is being resolved right now: Also there is still maintenance
of Linux/68k 0.9.x, the state of the art kernel is 1.2.13 which
is equivalent to the main kernel. All you need to do is to apply
ONE patch.
Bruce> 2. LILO and its ilk don't apply to other architectures.
There are counterparts of lilo et al. for Linux/68k. It is easy
to support several of them on a per-architecture basis until
the have been merged.
Bruce> 3. Does GAS support your instruction set?
Linux/68k is stable and fully operational, that includes a
working ELF libc as well as all development tools,
Bruce> 4. bin86 doesn't apply.
No big deal, more important is an replace ment of the sync(8)
command written in 386 assembly language. (No big deal either
but IMHO it was a mistake to switch from C to ASM at all!)
Bruce> 5. Has gcc/g++ been retargeted to your architecture?
See above.
Bruce> You can probably bring up more. We might eventually
Bruce> consider adding arch/{386,68k,alpha,arm,ppc} directories to
Bruce> our source tree, so that things like bin86 can be segrated
Bruce> from the architecture-independent software.
That is not really neccessary. What is more important is to have all
debian.rules files to behave the same. IMHO the best way to do this
is to have a look at the 4.4BSD make (aka pmake) and create a set
of include files to be read. Since dpkg is needed anyway to use these
files the includes could be distributed along side with it.
AND DON'T FORGET TO SUPPORT A SITE-DEFAULTS FILE !
Anyway all that would be needed to support different archs would then
be:
#! /usr/bin/make -I /usr/lib/dpkg/mk -f
# Determine architecture and setup make variables like CFLAGS
include debian.mk
# Debian package information
P=foobar
V=1.0
R=0
PROG=foobar
MAN1=foobar.1
INFO=foobar.info
SRCS=foo.c bar.c
SRCS+=asmstuff-$(ARCH).S
include package.mk
That is of course only a very simple example. For some packages you
will need to distinguish on program level, otheres will require
different dependencies. But this way it can be worked out transparent
to the user. Maybe the dpkg tool needs an ARCH field in its control
files as well ...
Bruce> I would hope that the ELF format, the mmap interface, and
Bruce> the kernel API would insulate most user-mode programs from
Bruce> any architecture-dependence. If programs are using
Bruce> assembler, either through asm statements or .s files, I'd
Bruce> hope they would also provide a C equivalent.
True. But there is something else about it:
I think it is about time to discuss /usr/share again, something which
is not yet covered by the File System Standard and not yet used by
DEBIAN. This is important if you have a couple of DEBIAN systems of
different architectures. It is even helpful if you have a couple
of identical systems! So far the only weakness of DEBIAN that i have
encountered is that a setup with shared resources is difficult to
administrate. For example if /usr/X11R6 is a shared NFS volume which
is only exported as read-only (as it should be), then a use of dpkg
to upgrade it is nearly impossible. If you extend this to a setup
with different architectures, then you have the situation that
the INSTALLATION PATH is most likely different from the RUN-TIME
PATH. That is you install the package as eg. /exports/X11R6/${ARCH}
but it is mounted as /usr/X11R6.
I know what you will say now: ok then export it to one system as
read-write and do the upgrade there. Ok, but then the information
held by /var/lib/dpkg/status on each system is not consistent any more.
And what if the package needs directories under the /var hierarchy
And what about diskless or dataless clients? I know a Linux 'cluster'
where /usr is exported via NFS read-only! And it works, but you have
a hell of a job updating that setup.
As you see there are still a lot of issues to be discussed!
Yours,
Dominik Kubla
(aka Mr. Linux)
Reply to: