[PATCH] Documentation: cover CONFIG_BINFMT_SCRIPT in init.txt

[PATCH] Documentation: cover CONFIG_BINFMT_SCRIPT in init.txt

[Kris Rusocki]

From: Kris Rusocki <kszysiu@braxis.org>

Now that binfmt_script is configurable, explain yet another possible
cause of boot failure (a script w/CONFIG_BINFMT_SCRIPT != y).

Signed-off-by: Kris Rusocki <kszysiu@braxis.org>
---
 Documentation/init.txt |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/init.txt b/Documentation/init.txt
index 535ad5e..8c6af4f 100644
--- a/Documentation/init.txt
+++ b/Documentation/init.txt
@@ -29,8 +29,9 @@
 E) make sure the binary's architecture matches your hardware.
    E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARM hardware.
    In case you tried loading a non-binary file here (shell script?),
-   you should make sure that the script specifies an interpreter in its shebang
-   header line (#!/...) that is fully working (including its library
+   you should make sure that your kernel supports script execution
+   (CONFIG_BINFMT_SCRIPT=y) and the script specifies an interpreter in its
+   shebang header line (#!/...) that is fully working (including its library
    dependencies). And before tackling scripts, better first test a simple
    non-script binary such as /bin/sh and confirm its successful execution.
    To find out more, add code to init/main.c to display kernel_execve()s

Re: [PATCH] Documentation: cover CONFIG_BINFMT_SCRIPT in init.txt

[Andreas Mohr]

On Thu, May 30, 2013 at 01:24:15PM -0600, Kris Rusocki wrote:
> From: Kris Rusocki <kszysiu@braxis.org>
> 
> Now that binfmt_script is configurable, explain yet another possible
> cause of boot failure (a script w/CONFIG_BINFMT_SCRIPT != y).

Nice catch, and thanks for your effort!

It's somewhat sad to see that that file remained at only one initial commit
since 2010, thus thumbs up for your help!

Docs in general seem to be a wee bit too unmaintained.

Acked-by: Andreas Mohr <andi@lisas.de>

Re: [PATCH] Documentation: cover CONFIG_BINFMT_SCRIPT in init.txt

[Rob Landley]

On 05/30/2013 03:33:10 PM, Andreas Mohr wrote:
> On Thu, May 30, 2013 at 01:24:15PM -0600, Kris Rusocki wrote:
> > From: Kris Rusocki <kszysiu@braxis.org>
> >
> > Now that binfmt_script is configurable, explain yet another possible
> > cause of boot failure (a script w/CONFIG_BINFMT_SCRIPT != y).
> 
> Nice catch, and thanks for your effort!
> 
> It's somewhat sad to see that that file remained at only one initial  
> commit
> since 2010, thus thumbs up for your help!
> 
> Docs in general seem to be a wee bit too unmaintained.

Are you volunteering?

Rob

Re: [PATCH] Documentation: cover CONFIG_BINFMT_SCRIPT in init.txt

[Andreas Mohr]

Hi,

On Mon, Jun 03, 2013 at 06:16:12AM -0500, Rob Landley wrote:
> On 05/30/2013 03:33:10 PM, Andreas Mohr wrote:
> >It's somewhat sad to see that that file remained at only one
> >initial commit
> >since 2010, thus thumbs up for your help!
> >
> >Docs in general seem to be a wee bit too unmaintained.
> 
> Are you volunteering?

Yeah (sort of ;) - in fact I keep piling up some doc updates locally
and am just waiting for them to reach critical mass
(but first I need to get some certain driver updates submitted anyway).

Andreas Mohr

Re: [PATCH] Documentation: cover CONFIG_BINFMT_SCRIPT in init.txt

[Rob Landley]

On 06/03/2013 03:26:56 PM, Andreas Mohr wrote:
> Hi,
> 
> On Mon, Jun 03, 2013 at 06:16:12AM -0500, Rob Landley wrote:
> > On 05/30/2013 03:33:10 PM, Andreas Mohr wrote:
> > >It's somewhat sad to see that that file remained at only one
> > >initial commit
> > >since 2010, thus thumbs up for your help!
> > >
> > >Docs in general seem to be a wee bit too unmaintained.
> >
> > Are you volunteering?
> 
> Yeah (sort of ;) - in fact I keep piling up some doc updates locally
> and am just waiting for them to reach critical mass
> (but first I need to get some certain driver updates submitted  
> anyway).
> 
> Andreas Mohr

No one person is an expert in every file in Documentation. My big todo  
items are centered around librarian work: reorganizing the layout of  
the directory so it's not a giant heap with everybody in the world  
dumping stuff into the root directory, or weird little crevices like  
pti/ and pps/ that have their own directory with one file in it.

Unfortunately, Documentation is the greatest source of bikeshedding in  
the kernel. Even as the directory's nominal maintainer, I can't say  
"translations don't belong in there, they belong on the web" because  
Greg KH thinks they do so he'll check them in anyway. And then nobody  
maintains them because anybody who can read the english versions (and  
thus update the translations) doesn't need the translations.

There's functional stuff in there like the devicetree bindings. There's  
a Makefile that compiles stuff under Documentation, and not just the  
htmldocs but actual code. I still don't really know why...

Unfortunately, I only really get time to deal with this sort of thing  
in the downtime between contracts, and last time I had a gap the  
massive barn-door-locking after the kernel.org breakin still had my  
account disabled because I hadn't been to an in-person conference to  
get a new pgp key signed in years. (And now that I've been to a  
conference and gotten one signed, I need to sit down and write a new  
rsync replacement on top of kup because non-security people wrote a  
bespoke security wrapper for kernel.org to replace shell access, which  
means my old rsync script that updated http://kernel.org/doc needs to  
be replaced with a rube goldberg monstrosity to do the same thing in a  
much more complicated and less efficient way.)

It's on the todo list. (You may have noticed I'm a couple days behind  
on just email. Next scheduled gap's in August...)

Rob

Re: [PATCH] Documentation: cover CONFIG_BINFMT_SCRIPT in init.txt

[Andreas Mohr]

On Thu, Jun 06, 2013 at 08:33:20PM -0500, Rob Landley wrote:
> No one person is an expert in every file in Documentation. My big
> todo items are centered around librarian work: reorganizing the
> layout of the directory so it's not a giant heap with everybody in
> the world dumping stuff into the root directory, or weird little
> crevices like pti/ and pps/ that have their own directory with one
> file in it.

Indeed, layout in kernel could be improved somewhat.
Would be nice to find a layout that's suitably organized
and more or less tries to *match* a good future
(since it does not quite seem to exist yet) layout in Kconfig areas
(where it's increasingly difficult to find things easily
due to number of possibilities growing massively thanks to many
new drivers and not enough obvious higher-level abstraction).
Once you are asked to go beyond the third page in specific
dialog-based menuconfig sections (e.g. drivers)
you might just as well choose to enter minotaur labyrinth... :)
Of course that's needed for manual changes only (make oldconfig does the rest),
but it remains sufficiently painful.

> Unfortunately, Documentation is the greatest source of bikeshedding
> in the kernel. Even as the directory's nominal maintainer, I can't
> say "translations don't belong in there, they belong on the web"
> because Greg KH thinks they do so he'll check them in anyway. And
> then nobody maintains them because anybody who can read the english
> versions (and thus update the translations) doesn't need the
> translations.

Rock <-> hard place. :)

The question here might simply be: what's Best Practice (tm) for
dealing with translations? Unless that (I'm sure...) happens to not exist... ;)

> There's functional stuff in there like the devicetree bindings.
> There's a Makefile that compiles stuff under Documentation, and not
> just the htmldocs but actual code. I still don't really know why...

Huh? Wow.

But then a
git log -p Documentation/Makefile
easily answers it:
it's exclusively for "documentation-side" sample source files,
to ensure that they always remain correctly buildable/working samples
of source code.

> Unfortunately, I only really get time to deal with this sort of
> thing in the downtime between contracts, and last time I had a gap
> the massive barn-door-locking after the kernel.org breakin still had
> my account disabled because I hadn't been to an in-person conference
> to get a new pgp key signed in years. (And now that I've been to a
> conference and gotten one signed, I need to sit down and write a new
> rsync replacement on top of kup because non-security people wrote a
> bespoke security wrapper for kernel.org to replace shell access,
> which means my old rsync script that updated http://kernel.org/doc
> needs to be replaced with a rube goldberg monstrosity to do the same
> thing in a much more complicated and less efficient way.)

Ouch.

Count me in on the huge "people in need of sufficiently recognized pgp signing"
list, though ;)

Andreas Mohr

-- 
GNU/Linux. It's not the software that's free, it's you.