Re: what is the whole purpose of kernel-image-di?

2001-02-16 Thread Daniel Jacobowitz

On Fri, Feb 16, 2001 at 10:56:24AM -0700, Randolph Chung wrote:
> > libdetect.  Someone KILL libdetect.
> > 
> > It has fledgling PPC support, but it's (A) hacked together awfully (B)
> > a little lacking in correctness (C) nowhere near compiling.  I got it
> > to build once, with two hours work, but not function.
> 
> hmm.. drow, I'd like to talk to you about this more... am looking into
> doing autodetection stuff for woody b-f using libdetect, but that might
> not be such a good idea if it's very i386 specific.

In fact, I just saw that other message in which you mentioned the idea
and was about to answer...

libdetect COULD be made more cross-platform friendly, by giving it some
sane rewriting.  It's a mess.

> > cdebconf.  Randolph, please do something about the warning and error I
> > showed you from the preinst (?)!
> 
> been on a road a lot this last few weeks. will fix on tuesday when i get
> back.

Thanks.

Dan

/\  /\
|   Daniel Jacobowitz|__|SCS Class of 2002   |
|   Debian GNU/Linux Developer__Carnegie Mellon University   |
| [EMAIL PROTECTED] |  |   [EMAIL PROTECTED]  |
\/  \/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-16 Thread Randolph Chung

> libdetect.  Someone KILL libdetect.
> 
> It has fledgling PPC support, but it's (A) hacked together awfully (B)
> a little lacking in correctness (C) nowhere near compiling.  I got it
> to build once, with two hours work, but not function.

hmm.. drow, I'd like to talk to you about this more... am looking into
doing autodetection stuff for woody b-f using libdetect, but that might
not be such a good idea if it's very i386 specific.

> cdebconf.  Randolph, please do something about the warning and error I
> showed you from the preinst (?)!

been on a road a lot this last few weeks. will fix on tuesday when i get
back.

randolph
-- 
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-11 Thread Daniel Jacobowitz

On Tue, Feb 06, 2001 at 10:34:52PM -0800, Joey Hess wrote:
> Daniel Jacobowitz wrote:
> > 2.4.1 kernel.org does not build on PPC.  Sigh.
> 
> 2.4.0 is ok, right? I guess I'll hold off of 2.4.1 for now..

Not sure.

> > Other architectures will want a radically simplified detection scheme. 
> > PPC (mostly) has no legacy ISA or such; everything should show up in
> > the kernel's PCI probes.  That should make things much nicer.
> 
> Hardware detection is a place where despite Ben's protests, modularity
> really does work. For i386 network cards, we have ethdetect which
> autoprobes the card and loads the driver. For sparc we can have an
> essentially dummy package that makes sure one of the drivers built into
> the kernel found something. For ppc we can do something else. Other modules 
> that need to actually make use of the network connection then depend on a 
> virtual package that is provided by all of the above.

I'd rather separate PCI detection out from legacy detection in a common
ethdetect module, honestly.  That'll work exactly the same.

Dan

/\  /\
|   Daniel Jacobowitz|__|SCS Class of 2002   |
|   Debian GNU/Linux Developer__Carnegie Mellon University   |
| [EMAIL PROTECTED] |  |   [EMAIL PROTECTED]  |
\/  \/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-10 Thread Marcus Brinkmann

On Wed, Feb 07, 2001 at 05:07:28PM +1100, Glenn McGrath wrote:
> I just tried compiling stuff by hand for hurd-i386, the following
> components form cvs compile fine
> 
> anna
> cdebconf
> choose-mirror
> main-menu
> udpkg
> wget

Can you compile and upload the packages? There is currently no functional
autobuilder for the Hurd (because of a network server bug).
 
> I tried dpkg-buildpackage on a couple of these they fail because they
> need debhelper which i couldnt install because it depends on dpkg which
> conflicts with dpkg-hurd, no doubt this is why autobuilders would fail.
> I havent look any deeper yet.

(I saw your other mail where you say dpkg-hurd-dev and dpkg-dev).
dpkg-hurd-dev is long obsolete, using dpkg-dev should work just fine.

Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Ethan Benson

On Tue, Feb 06, 2001 at 10:34:52PM -0800, Joey Hess wrote:
> Daniel Jacobowitz wrote:
> > 2.4.1 kernel.org does not build on PPC.  Sigh.
> 
> 2.4.0 is ok, right? I guess I'll hold off of 2.4.1 for now..

2.4.0 is even worse (read useless) on powerpc.  (linus merged some
2.4 powerpc code in 2.4.1 but obviously not enough)

at the moment the only 2.4 kernel code that works on powerpc is the
forked bk trees.  2.2.18 kernel.org however is fully powerpc
functional.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

 PGP signature


Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Joey Hess

Daniel Jacobowitz wrote:
> 2.4.1 kernel.org does not build on PPC.  Sigh.

2.4.0 is ok, right? I guess I'll hold off of 2.4.1 for now..

> Other architectures will want a radically simplified detection scheme. 
> PPC (mostly) has no legacy ISA or such; everything should show up in
> the kernel's PCI probes.  That should make things much nicer.

Hardware detection is a place where despite Ben's protests, modularity
really does work. For i386 network cards, we have ethdetect which
autoprobes the card and loads the driver. For sparc we can have an
essentially dummy package that makes sure one of the drivers built into
the kernel found something. For ppc we can do something else. Other modules 
that need to actually make use of the network connection then depend on a 
virtual package that is provided by all of the above.

-- 
see shy jo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Joey Hess

Ben Collins wrote:
> Well sparc needs three kernels. sun4cdm, sun4dm-pci and sun4u. I can get
> you configs, but the problem being that I have no idea what kernel
> source you are building. I would hope that you plan to integrate to
> 2.4.x sooner or later, but how will you notify ports of this new change?
> No one asked about such configs yet. I guess what I am saying is that it
> would be nice if you could communicate this outside of the debian-boot
> list (say to the nice [EMAIL PROTECTED] alias I have made :)

kernel-image-di is using for 2.4.0, will build for 2.4.1 once source
for that enters the debian archive. See its build dependancies; the
build dependancies will ensure it is autobuilt with the right kernel.

> > c. Some things such as network card involve hardware autodetection. We have
> >concentrated on i386 since it has the most variety (and crap) hardware.
> >udebs are generally available which let the user specify it manually
> >instead of using hardware autodetection. Other than those and some minor
> >crossovers, other architectures are on their own, and someone will have to
> >work on it.
> 
> Well sparc is quite simple in this regard. We have the special ability
> to just build all the standard NIC drivers right into the main image.
> The only modules I can think of needing are for the gigabit, but I
> imagine those are not needed for the installer, since nearly every sparc
> has one of the standard cards built-in.

The reason to use modules is mainly one of space on the boot media. If
that is not a concern on sparc they could be built in.

> That's fine, but is it even a concern to have such a checklist, or is me
> bringing it up the first of it's discussion? Are you expecting porters
> to do all the work trying to figure out what they need to do once the
> installer is nearly complete?

No, I'm really expecting porters to jump in now and help us. We have a
very small group working on this.

> support, then piss on debinst. One issue that comes to mind was the past
> discussion about using the module utilities from busybox, which would
> have totally killed some ports (sun4u being one of them). Things like
> that need the concern of more than just one or two archs. The other is
> the nano editor, which has asm for i386 only (or maybe some other archs,
> but surely not sparc). This means we don't get the space savings that
> i386 does (it has to link to libc).
> 
> Other choices may include things like parted, which doesn't support all
> archs, but I hear it is a likely candidate for a partion program. Yet
> more things to shutdown certain ports from using the standard install.
> Of course it isn't a reason not to use it, just that concerns need to be
> raised.

As far as I can see, they have been. After all we didn't wander off and
use the busymox insmod, iirc the issues with parted have been brought up
before, and now I know about nano (which exists as a udeb just because
its mtaintainer wanted to do it iirc; we haven't really talked about
editors yet).

I encourage you and anyone else to read this list and keep us in line if
we begin to wander off into i386 la-la land. I also encorage people
involved in other architectures to begin participating in the creation
of debian-installer *now* so they can have a hand in making it work well
on those platforms.

-- 
see shy jo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Glenn McGrath

Glenn McGrath wrote:

> I tried dpkg-buildpackage on a couple of these they fail because they
> need debhelper which i couldnt install because it depends on dpkg which
> conflicts with dpkg-hurd, no doubt this is why autobuilders would fail.
> I havent look any deeper yet.
> 

i should have said dpkg-dev and dpkg-hurd-dev instead of depk and
dpkg-hurd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Glenn McGrath

Joey Hess wrote:
> 
> Ben Collins wrote:
> > I can understand it being the first milestone, but it seems to be the
> > only focus, and nothing is being considered as to how it affects other
> > ports.
> 
> A glance at the debian archive shows that this many udebs have been ported:
> 
> joeyh@auric:/org/ftp.debian.org/ftp/dists/sid/main/debian-installer>for dir in * ; 
>do echo -n $dir ; grep Package: $dir/Packages |wc -l ; done
> binary-alpha  9
> binary-arm  6
> binary-hppa  1
> binary-hurd-i386  1
> binary-i386 22
> binary-ia64  1
> binary-m68k  4
> binary-mips  3
> binary-mipsel  1
> binary-powerpc 11
> binary-s390  1
> binary-sh  1
> binary-sparc  8
> 
> This is one of the nice things about the debian-installer using standard debian
> sources that generate deb files: autobuilders automatically treat d-i modules
> just like regular packages. Anyone want to go check the build logs for
> problems to see if some of the missing items failed to build or have just not
> need attempted yet?
> 

I just tried compiling stuff by hand for hurd-i386, the following
components form cvs compile fine

anna
cdebconf
choose-mirror
main-menu
udpkg
wget

The hardware detection stuff doesnt apply to hurd as it all at least in
part depends on /proc which is a linux, so any hardware detection for
the hurd is going to have to be native, configuring may also have to be
somewhat different as well as the Hurd uses a translators to setup some
hardware.

I tried dpkg-buildpackage on a couple of these they fail because they
need debhelper which i couldnt install because it depends on dpkg which
conflicts with dpkg-hurd, no doubt this is why autobuilders would fail.
I havent look any deeper yet.

A previous holdup for the Hurd was partitioning software, work is
underway to port parted, so that should fix that problem. 



Glenn


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Daniel Jacobowitz

On Tue, Feb 06, 2001 at 09:09:28PM -0800, Joey Hess wrote:
> Ben Collins wrote:
> > I can understand it being the first milestone, but it seems to be the
> > only focus, and nothing is being considered as to how it affects other
> > ports.
> 
> That's not entirely true; I know of a group (who I cannot name or go
> into any detail on since they told me about this privatly) who is using
> the the basic debian-installer design and code as the base for something
> (very cool) involving installation on powerpc. The pa-risc porters were 
> also looking at using d-i some months back, but it wasn't far enough along
> at that point.


Now I'm curious, curse you!

> Oh by the way Dan has been involved earlier in porting most of the d-i
> modules to the powerpc, or rather, compiling them on the powerpc. They
> seemed to work ok, but this was a while back, before the system did
> anything.

And I'm going to go back to this shortly, now that we've got an x86
bootable floppy.  PowerPC is not big on bootable floppies (or floppies
at all) but I can probably get a nice ramdisk going, and maybe a
netboot...

> This is one of the nice things about the debian-installer using standard debian
> sources that generate deb files: autobuilders automatically treat d-i modules
> just like regular packages. Anyone want to go check the build logs for 
> problems to see if some of the missing items failed to build or have just not
> need attempted yet?

libdetect.  Someone KILL libdetect.

It has fledgling PPC support, but it's (A) hacked together awfully (B)
a little lacking in correctness (C) nowhere near compiling.  I got it
to build once, with two hours work, but not function.

cdebconf.  Randolph, please do something about the warning and error I
showed you from the preinst (?)!

> b. Send me an appropriate kernel config and related information, and build
>kernel-image-di once I integrate it.

2.4.1 kernel.org does not build on PPC.  Sigh.

> c. Some things such as network card involve hardware autodetection. We have
>concentrated on i386 since it has the most variety (and crap) hardware.
>udebs are generally available which let the user specify it manually
>instead of using hardware autodetection. Other than those and some minor
>crossovers, other architectures are on their own, and someone will have to
>work on it.

Other architectures will want a radically simplified detection scheme. 
PPC (mostly) has no legacy ISA or such; everything should show up in
the kernel's PCI probes.  That should make things much nicer.

Dan

/\  /\
|   Daniel Jacobowitz|__|SCS Class of 2002   |
|   Debian GNU/Linux Developer__Carnegie Mellon University   |
| [EMAIL PROTECTED] |  |   [EMAIL PROTECTED]  |
\/  \/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Ben Collins

On Tue, Feb 06, 2001 at 09:09:28PM -0800, Joey Hess wrote:
> b. Send me an appropriate kernel config and related information, and build
>kernel-image-di once I integrate it.

Well sparc needs three kernels. sun4cdm, sun4dm-pci and sun4u. I can get
you configs, but the problem being that I have no idea what kernel
source you are building. I would hope that you plan to integrate to
2.4.x sooner or later, but how will you notify ports of this new change?
No one asked about such configs yet. I guess what I am saying is that it
would be nice if you could communicate this outside of the debian-boot
list (say to the nice [EMAIL PROTECTED] alias I have made :)

> c. Some things such as network card involve hardware autodetection. We have
>concentrated on i386 since it has the most variety (and crap) hardware.
>udebs are generally available which let the user specify it manually
>instead of using hardware autodetection. Other than those and some minor
>crossovers, other architectures are on their own, and someone will have to
>work on it.

Well sparc is quite simple in this regard. We have the special ability
to just build all the standard NIC drivers right into the main image.
The only modules I can think of needing are for the gigabit, but I
imagine those are not needed for the installer, since nearly every sparc
has one of the standard cards built-in.

> d. The build/ directory is what builds actual bootable media. That code is
>currently flagged:
># Create a bootable floppy image. i386 specific. FIXME
>Obviously that will need to be fixed, on a case-by-case basis. I personally
>flag anything I do that is i386-specific as such, although I haven't
>had to do that much so far. 
> 
> But we're really all too busy writing this thing to have ready-made checklists
> yet. I'm scrambling to keep the existing design documentation current.

That's fine, but is it even a concern to have such a checklist, or is me
bringing it up the first of it's discussion? Are you expecting porters
to do all the work trying to figure out what they need to do once the
installer is nearly complete?

> > Note, every arch is different, which was the main reason for so much
> > speciality and hacking in the boot-floppies. It's held together by
> > ducktape and string. Have the issues involved in the boot-floppies
> > struggle with multi-platform support been brought into consideration of
> > the debinst design?
> 
> You're not going to magically get a new installer for your architecture
> dropped in your lap, it will take work. Anyone is free to jump in and make
> support for another architecture happen *now*, while we are still in the
> middle of writing the thing. Or you can wait and complain after the fact 
> about us not anticipating the needs of every architecture. Up to you.

I'm not asking for a free-installer. What I'm asking for is
concentration on porting specifics. Not all porters can keep up with the
entire installer code base, and simply want to know "what do I have to
do to get support for my arch in the installer?". If I have to go
through the whole source tree searching for "i386.*FIXME", it's going to
be slow and tedious. I'm not expecting anyone to do the work for me, but
as the developers of the software, I would hope that keeping known
concerns about porting in the focus of the project would be a main
concern.

Obviously if I jump up and say "well arch foo needs 10 special udeb's,
why don't you have them!", well piss on me. But if I turn around and see
that there is no way for me to even have subarch (sun4cdm, sun4u)
support, then piss on debinst. One issue that comes to mind was the past
discussion about using the module utilities from busybox, which would
have totally killed some ports (sun4u being one of them). Things like
that need the concern of more than just one or two archs. The other is
the nano editor, which has asm for i386 only (or maybe some other archs,
but surely not sparc). This means we don't get the space savings that
i386 does (it has to link to libc).

Other choices may include things like parted, which doesn't support all
archs, but I hear it is a likely candidate for a partion program. Yet
more things to shutdown certain ports from using the standard install.
Of course it isn't a reason not to use it, just that concerns need to be
raised.

Please don't think I am complainging about what work I will have to do,
or that you guys aren't doing enough, I'm just concerned about a lot of
work being done without enough consideration for the effects on other
ports.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL

Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Joey Hess

Ben Collins wrote:
> I can understand it being the first milestone, but it seems to be the
> only focus, and nothing is being considered as to how it affects other
> ports.

That's not entirely true; I know of a group (who I cannot name or go
into any detail on since they told me about this privatly) who is using
the the basic debian-installer design and code as the base for something
(very cool) involving installation on powerpc. The pa-risc porters were 
also looking at using d-i some months back, but it wasn't far enough along
at that point.

> For sparc, there has to be atleast two different boot kernels. One for
> sun4cdm (32bit CPU), and one for sun4u (64bit CPU).

As Glenn said, the kernel-image-di kernel is intended to have initrd and
ext2 built in, plus anything else needed to boot the system from initrd
and get a console. Everything else should be configured as a module. As
I told Daniel Jacobowitz when he asked about powerpc (unrelated to thing
above), send me a .config file and any logic necessary to detect the
arch (and subarchitectures), and I will integrate it into the package. 
I will also need various lists of module names, like a list of common NIC
card modules and so on.

Oh by the way Dan has been involved earlier in porting most of the d-i
modules to the powerpc, or rather, compiling them on the powerpc. They
seemed to work ok, but this was a while back, before the system did
anything.

A glance at the debian archive shows that this many udebs have been ported:

joeyh@auric:/org/ftp.debian.org/ftp/dists/sid/main/debian-installer>for dir in * ; do 
echo -n $dir ; grep Package: $dir/Packages |wc -l ; done
binary-alpha  9
binary-arm  6
binary-hppa  1
binary-hurd-i386  1
binary-i386 22
binary-ia64  1
binary-m68k  4
binary-mips  3
binary-mipsel  1
binary-powerpc 11
binary-s390  1
binary-sh  1
binary-sparc  8

This is one of the nice things about the debian-installer using standard debian
sources that generate deb files: autobuilders automatically treat d-i modules
just like regular packages. Anyone want to go check the build logs for 
problems to see if some of the missing items failed to build or have just not
need attempted yet?

(Good grief, I didn't know binary-ia64 had made it into the archive already..)

> My main concern is whether or not it
> is being documented as to how other ports need to handle getting the
> installer working for it. Is there a checklist of what a port needs in
> order to have support in the installer, such as a minimum of required
> packages (boot loader setup, kernel-images, etc.)?

Breifly:

a. Autobuild all the udebs. File RC bugs on any that fail to build, per
   the usual. If you just want to build a few, build those listed in 
   build/lists/base, although you'll need at least one additional set, like 
   build/lists/net to actually have a useful system.
b. Send me an appropriate kernel config and related information, and build
   kernel-image-di once I integrate it.
c. Some things such as network card involve hardware autodetection. We have
   concentrated on i386 since it has the most variety (and crap) hardware.
   udebs are generally available which let the user specify it manually
   instead of using hardware autodetection. Other than those and some minor
   crossovers, other architectures are on their own, and someone will have to
   work on it.
d. The build/ directory is what builds actual bootable media. That code is
   currently flagged:
   # Create a bootable floppy image. i386 specific. FIXME
   Obviously that will need to be fixed, on a case-by-case basis. I personally
   flag anything I do that is i386-specific as such, although I haven't
   had to do that much so far. 

But we're really all too busy writing this thing to have ready-made checklists
yet. I'm scrambling to keep the existing design documentation current.

> Note, every arch is different, which was the main reason for so much
> speciality and hacking in the boot-floppies. It's held together by
> ducktape and string. Have the issues involved in the boot-floppies
> struggle with multi-platform support been brought into consideration of
> the debinst design?

You're not going to magically get a new installer for your architecture
dropped in your lap, it will take work. Anyone is free to jump in and make
support for another architecture happen *now*, while we are still in the
middle of writing the thing. Or you can wait and complain after the fact 
about us not anticipating the needs of every architecture. Up to you.
 
-- 
see shy jo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Ben Collins

On Wed, Feb 07, 2001 at 06:34:59AM +0200, Eray Ozkural (exa) wrote:
> Ben Collins wrote:
> > 
> > For sparc, there has to be atleast two different boot kernels. One for
> > sun4cdm (32bit CPU), and one for sun4u (64bit CPU). SPARC also supports
> > native netbooting (via RARP/TFTP). My main concern is whether or not it
>   ^
> 
> One of the things we should be working out. I sweated for quite a few hours
> to get my second i386 box netboot. It would be great if we could
> have the system use netboot on platforms where it's possible.

The installer does not need to directly support net booting, atleast not
on sparc. All it needs is for the rootfs image, and a kernel image. Then
it boots the same as if it were an initrd.

However, creating this needs to be done somehow, and done from a
scripted setup (IOW, in a reproducable way).

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Eray Ozkural (exa)

Ben Collins wrote:
> 
> For sparc, there has to be atleast two different boot kernels. One for
> sun4cdm (32bit CPU), and one for sun4u (64bit CPU). SPARC also supports
> native netbooting (via RARP/TFTP). My main concern is whether or not it
  ^

One of the things we should be working out. I sweated for quite a few hours
to get my second i386 box netboot. It would be great if we could
have the system use netboot on platforms where it's possible.


As you mention, the complexities involved in porting may be overwhelming
if we leave porting as an afterthought. I'd guess that some documentation
would be in order. Can not we extract the dependencies and problems
with different architectures from the existing boot-floppies docs and
source somehow? Perhaps then some sort of a checklist for ports might be done,
not enough time to re-invent the wheel.

Another thing concerning me would be keeping linuxisms to a minimum and
see if we can support hurd in a good way. That would even help freebsd
and other exotic ports (cygwin anyone?) out there. 

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Ben Collins

On Wed, Feb 07, 2001 at 02:12:43PM +1100, Glenn McGrath wrote:
> Ben Collins wrote:
> > 
> > I'm sitting here looking at an obvious build failure for
> > kernel-image-di on the sparc buildd, and I'm wondering what the heck
> > this package is for anyway. I mean, is this thing supposed to be
> > portable? If it is, it sucks at doing so, and if it's not, then is it
> > the intention that non-i386 is left out of this loop?
> > 
> > Are the debinst folks not even considering non-i386 ports during
> > this development process? Am I going to have to go through all of the
> > installer and hack it to bits to make it work on sparc, just as I had to
> > do with boot-floppies, or is debian-installer being developed so that
> > all I have to do is create a boot-block installer, and a set of
> > kernel-image*.udeb packages to get it working on sparc? I'm very
> > concerned that portability is becoming an afterthought.
> > 
> 
> Network install to a i386 was/is the initial focus of development, but
> the modular nature of d-i should make it easy(or easier) to overcome any
> difficulties with a specific architecture, or even a different type of
> kernel (native Hurd install).

I can understand it being the first milestone, but it seems to be the
only focus, and nothing is being considered as to how it affects other
ports.

> Probably a lot of people (me included) arent aware of the difficulties
> of specific architectures, can you go into a bit of detail about what
> kernel config doesnt work for sparc ? 

For sparc, there has to be atleast two different boot kernels. One for
sun4cdm (32bit CPU), and one for sun4u (64bit CPU). SPARC also supports
native netbooting (via RARP/TFTP). My main concern is whether or not it
is being documented as to how other ports need to handle getting the
installer working for it. Is there a checklist of what a port needs in
order to have support in the installer, such as a minimum of required
packages (boot loader setup, kernel-images, etc.)?

Note, every arch is different, which was the main reason for so much
speciality and hacking in the boot-floppies. It's held together by
ducktape and string. Have the issues involved in the boot-floppies
struggle with multi-platform support been brought into consideration of
the debinst design?

> To answer your last question specifically, portability isnt an
> afterthought, its part of the design due to modularity.

Sorry, but modularity does not beget portability. This assumption will
end up biting us in the ass later, if it is the only premise for
"portability".

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: what is the whole purpose of kernel-image-di?

2001-02-06 Thread Glenn McGrath

Ben Collins wrote:
> 
> I'm sitting here looking at an obvious build failure for
> kernel-image-di on the sparc buildd, and I'm wondering what the heck
> this package is for anyway. I mean, is this thing supposed to be
> portable? If it is, it sucks at doing so, and if it's not, then is it
> the intention that non-i386 is left out of this loop?
> 
> Are the debinst folks not even considering non-i386 ports during
> this development process? Am I going to have to go through all of the
> installer and hack it to bits to make it work on sparc, just as I had to
> do with boot-floppies, or is debian-installer being developed so that
> all I have to do is create a boot-block installer, and a set of
> kernel-image*.udeb packages to get it working on sparc? I'm very
> concerned that portability is becoming an afterthought.
> 

Network install to a i386 was/is the initial focus of development, but
the modular nature of d-i should make it easy(or easier) to overcome any
difficulties with a specific architecture, or even a different type of
kernel (native Hurd install).

Because installer modules are deb packages architecture dependent
packages for the installer can be handled in the same way an installed
system handles it.

The boot kernel is supposed to be very modular with only enough features
to work, its not neccesarily supposed to be the kernel that will be used
post install.

Probably a lot of people (me included) arent aware of the difficulties
of specific architectures, can you go into a bit of detail about what
kernel config doesnt work for sparc ? 

To answer your last question specifically, portability isnt an
afterthought, its part of the design due to modularity.


Glenn




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]