[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Yet another [cross] installer

On Tue, Mar 02, 2010 at 11:48:55AM -0500, JLB wrote:
> I have a suggestion. The best solution to the 'devices shipped with  
> hard/impossible-to-change binary kernels' problem, as far as I can tell,  
> would have to come not from the Debian team, but from the upstream kernel 
> team.
> Namely, if there was ALWAYS a way (which could not be turned off) to  
> extract a kernel's configuration (in a format which could be plunked into 
> /usr/src/linux and used to build new modules) from the running kernel,  
> things would be much simpler.
> Why this has not already been done is beyond me.
> Yes, it is nice that there is a kernel OPTION that makes the current  
> kernel config show up as /proc/config or whatnot. But there is certainly  
> room for a 'middle path', perhaps spitting out some fugly binary which 
> can be interpreted by an external program/script and thus -converted- 
> into a properly formatted config file.
> I have one of the CT-PC89E machines. It has a binary kernel. This kernel  
> is burned into a partition of the internal 2GB SSD which, as far as I can 
> tell, is not any known type of filesystem ('file', run on a dd dump of  
> this partition, just says 'data'; the only way to get any useful info out 
> of this partition's contents is to pass it through 'strings'). As has 
> been pointed out on this thread, the problem of devices shipped with  
> binary-only kernels is only going to get worse.
> It would be EXCELLENT if I could just run some external program and have  
> it dump a config file... Then I could go in and compile as many new  
> modules as I want. For example, ext3... which this machine's kernel lacks 
> support for!
> If every kernel in the future had a non-disableable ability to dump a  
> 'fingerprint' of its config data (even in some fugly format that required 
> an external program to interpret), then the Chinese manufacturers could  
> not pull this crap (not without explicitly editing the kernel source to  
> remove this feature, which I HIGHLY doubt most would bother with).

Of course embedded people hate wasted space, so they would insist on
being able to remove it.

And of course anyone that wants to remove it can, since they have
the source.

Not that a config is really all that helpful, given often you lack the
necesary drivers or kernel patches that were used in the first place.

Len Sorensen

Reply to: