Re: External install modules and compacted libc
> "Glenn" == Glenn McGrath <[EMAIL PROTECTED]> writes: Glenn> Supporting unplanned binaries is the big problem with Glenn> stripped libc, this may be a strange idea, would it be Glenn> possible at runtime to detect if a binary has failed due to Glenn> unsupported libc? Sure, it will segfault with an unresolvable symbol error. :) You can force this to happen sooner rather than later in the execution by using setting LD_BIND=now in the environment, IIRC. -- Stephen "Good idea, O Lord!"... "'Course it's a good idea!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: External install modules and compacted libc
On Mon, Sep 25, 2000 at 10:27:27AM +1100, Glenn McGrath wrote: > We can still have a non-striped libc (minus option?) in a module that > could be installed if it was needed. Library reduction is really only > critical for modules that will go on a boot/root floppy, modules that > will be sourced post bootup are less critical on space, it is likely > further modules will be residing on hard disk, cd or via the network. We > have to install the full libc sometime. Sure. > Supporting unplanned binaries is the big problem with stripped libc, > this may be a strange idea, would it be possible at runtime to detect if > a binary has failed due to unsupported libc? > > If we could detect the problem we could (try to) install the non-striped > libc, a bit like auto-apt. I don't think that would be helpful. I'd say install the full libc as early as possible. If anything fails before we can access an install media we are doomed. > > If the module comes on CD I see no problem with including the libc. > > > If there is a dependency heirarchy in the modules, then the libc symbols > included would only have to be those symbols not suplied by previous > modules. Now that would be a really ugly hack :) cu Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: External install modules and compacted libc
Torsten Landschoff wrote: > > On Fri, Sep 22, 2000 at 06:04:49PM -0700, Joey Hess wrote: > > [compacted libc problem] > > 2) Make sure all the installer modules are in a well-defined place in > >the debian archive, and download them all and analyize them all for > >library reduction. Each time a new version of a module is uploaded, > >we may need to update the libc to make sure it supports the symbols > >in it. > We can still have a non-striped libc (minus option?) in a module that could be installed if it was needed. Library reduction is really only critical for modules that will go on a boot/root floppy, modules that will be sourced post bootup are less critical on space, it is likely further modules will be residing on hard disk, cd or via the network. We have to install the full libc sometime. Supporting unplanned binaries is the big problem with stripped libc, this may be a strange idea, would it be possible at runtime to detect if a binary has failed due to unsupported libc? If we could detect the problem we could (try to) install the non-striped libc, a bit like auto-apt. > > > Including the libc with the modules doesn't seem any better than just > > statically linking the modules. Which I guess a third party could do in > > some situations in any case. > > If the module comes on CD I see no problem with including the libc. > If there is a dependency heirarchy in the modules, then the libc symbols included would only have to be those symbols not suplied by previous modules. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: External install modules and compacted libc
On Fri, Sep 22, 2000 at 06:04:49PM -0700, Joey Hess wrote: [compacted libc problem] > Yep, I've thought on it some before. There are two approaches I've come > up with: > > 1) Basically, define a policy that thou shalt use only these libc >functions in an installer module. Anyone who needs a new function has >to get it into the policy. That would be very error prone. Something along this line would be to compile a libc with everything optional switched off (I think this can be done with glibc, right?) and make that available saying "it has to work with this stripped libc". > 2) Make sure all the installer modules are in a well-defined place in >the debian archive, and download them all and analyize them all for >library reduction. Each time a new version of a module is uploaded, >we may need to update the libc to make sure it supports the symbols >in it. That would be better I think. > The problem with 2 is it requires more work, and third parties who make > installer modules have to consult some list still, except the list may > change without warning.. For 2 I would expect third parties to make their own boot floppies. > Including the libc with the modules doesn't seem any better than just > statically linking the modules. Which I guess a third party could do in > some situations in any case. If the module comes on CD I see no problem with including the libc. cu Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: External install modules and compacted libc
Torsten Landschoff wrote: > On Sun, Sep 17, 2000 at 04:29:11PM +1100, Glenn McGrath wrote: > > Yea, that is a problem that has been mentioned before, it is going to be > > tricky to get around cheaply. > > Hmm, do we have a list of "known/expected problems" somewhere? We do now. (doc/ISSUES in cvs) -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: External install modules and compacted libc
Torsten Landschoff wrote: > > The way modules will work is that they should only be called (or loaded) > > if needed, so its not a matter of disabling any modules, just only > > calling the modules you need, this is the key to shrinking the installer > > to 1 boot disk (with everything else being fetched as required). There > > I see a problem with the libc here. You know we are using a compact libc > for the current bootdisks with only so much in it as is needed by the > stuff in the root filesystem. If other modules will be available later > we might need more of libc. We either need to know the list of all > modules which might get available or the external modules need to come > with their own libc (which is certainly doable, only wanted to > put draw some attention to this problem). Yep, I've thought on it some before. There are two approaches I've come up with: 1) Basically, define a policy that thou shalt use only these libc functions in an installer module. Anyone who needs a new function has to get it into the policy. 2) Make sure all the installer modules are in a well-defined place in the debian archive, and download them all and analyize them all for library reduction. Each time a new version of a module is uploaded, we may need to update the libc to make sure it supports the symbols in it. The problem with 1 is that it introduces some very Debian-eque beauracracy, and third parties who make installer modules need to consult the approved function list. The problem with 2 is it requires more work, and third parties who make installer modules have to consult some list still, except the list may change without warning.. Including the libc with the modules doesn't seem any better than just statically linking the modules. Which I guess a third party could do in some situations in any case. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: External install modules and compacted libc
On Sun, Sep 17, 2000 at 04:29:11PM +1100, Glenn McGrath wrote: > Yea, that is a problem that has been mentioned before, it is going to be > tricky to get around cheaply. Hmm, do we have a list of "known/expected problems" somewhere? > If a module has pre-dependencies it only needs to carry the parts of the > libraries it needs that wernt supplied by the pre-dependencent modules. > Could get trick to implement though. Indeed! > We could have a libc module that provided the full library that could be > called on at some point, and everything prior to that point being either > static, or using a shared cutdown libc. Something like that would be desirable. Static linking is not an option on the boot floppies I guess since a single binary will be 200kb without doing much :( cu Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: External install modules and compacted libc
Torsten Landschoff wrote: > > On Sat, Sep 16, 2000 at 12:36:56PM +1100, Glenn McGrath wrote: > > The way modules will work is that they should only be called (or loaded) > > if needed, so its not a matter of disabling any modules, just only > > calling the modules you need, this is the key to shrinking the installer > > to 1 boot disk (with everything else being fetched as required). There > > I see a problem with the libc here. You know we are using a compact libc > for the current bootdisks with only so much in it as is needed by the > stuff in the root filesystem. If other modules will be available later > we might need more of libc. We either need to know the list of all > modules which might get available or the external modules need to come > with their own libc (which is certainly doable, only wanted to > put draw some attention to this problem). > > cu > > Torsten > Yea, that is a problem that has been mentioned before, it is going to be tricky to get around cheaply. If a module has pre-dependencies it only needs to carry the parts of the libraries it needs that wernt supplied by the pre-dependencent modules. Could get trick to implement though. And it becomes an issue that if a bigger heirarchy of pre-dependent modules are used then the later modules will be leaner as there libs will mostly be pre-provided, but this also makes the installer less flexible. We could have a libc module that provided the full library that could be called on at some point, and everything prior to that point being either static, or using a shared cutdown libc. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
