Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 19 Oct 2018, 14:17
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
Rationalisation of init
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 6 [88 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6 Next
Author Message
gyro

Joined: 28 Oct 2008
Posts: 1551
Location: Brisbane, Australia

PostPosted: Mon 20 Jun 2016, 16:04    Post subject: Where to from here?  

Following my success with testing aufs stacks in the "init" environment, I have a revised plan for updating the actual "init".

1. Cut search_func into 2, savefile/savefolder stuff becomes search_save_func
2. search_func is reduced to decoding all boot parameters and finding pup...sfs, setting PDEV1
if PDRVDEV is set:
if PDRVFN is empty set to PUPXXXSFS
if /mnt/pdrv$PSUBDIR/$PDRVFN exists, set PDEV1
else search for $PSUBDIR/$PUPXXXSFS as diligently as it was for "vmlinux", set PDEV1 if found
if PDEV1 set DEV1FS and other "vmlinux found" stuff
3. Remove all load sfs code from "LOADING PUPPY FILES" section
4. algorithm becomes:
do search_func stuff
load sfs's to pupmode=5 aufs stack
establish SAVEPART
do "insmod" stuff
do search_save_func
load savefile/savefolder
update aufs stack with savefile/savefolder
continue on to switch root
5. Complete change to use only a single tmpfs.
6. Cleanup more possibly reduntant code, e.g. setting the aufs layer variables in beginning of "LOADING PUPPY FILES" section.

As this has now become a coding exercise, when I have a modified "init" I will open a thread in "Cutting edge" for discussion of the code.

To encourage others to contribute, it might be handy to do this as a file on git-hub in a repository to which I, and others have direct access.
I'm not sure how to set that up.
@jlist, I don't have direct access to the initrd_progs repo.
At the moment the only git-hub repositories I have direct access to, are the forks in my git-hub account.
By "direct access" I mean something I can push "commits" to, using git on my local machine.

gyro
Back to top
View user's profile Send private message 
jlst

Joined: 23 Nov 2012
Posts: 571

PostPosted: Mon 20 Jun 2016, 17:53    Post subject:  

Ok gyro, initrd_progs is somewhat restricted to members of the team, those who have write access to all woofce repos, well, everybody else has to open pull requests ( just like i used to).

I'm certainly quick to merge pull requests so that could be the place, i also think you should a member, or at least have write access to that repo, i'll send a message to micko..

Well, this is what I used to do.... add commits then open a pull request every few days with all the commits... while the pull request was open i kept adding commits to document the changes.. initrd_progs is a place to experiment and push anything and that's what i did until it was ready....
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4841
Location: Blue Springs, MO

PostPosted: Mon 20 Jun 2016, 17:55    Post subject:  

I would suggest starting from this:
https://github.com/landley/aboriginal/blob/master/sources/root-filesystem/sbin/init.sh

Its pretty simplified already, but it unnecessarily parses /proc/cmdline - the kernel passes parameters of the format *=* to envp/environ (environment variable in shell) and other parameters without an equal sign to argv ($@ in shell)

In shell you can use a default variable parameter like this:
Code:
${init:-/linuxrc} #run the init set in the env var $init if it is set, otherwise run /linuxrc
or this:
Code:
#defaultinit=/init
defaultinit=/linuxrc
${init:-${defaultinit:-/init}}
#pass init=whatever on the kernel command line


for the kernel arguments without an equal sign:
Code:
while [ "$1" ]; do
case "$1" in
   quiet)QUIET=1;;
   #other cases here
   *): DO NOTHING;;
esac
shift
done
[ "$QUIET" ] || echo now doing step XX


BTW every single line of code involved with searching is bloat

_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
gyro

Joined: 28 Oct 2008
Posts: 1551
Location: Brisbane, Australia

PostPosted: Mon 20 Jun 2016, 19:39    Post subject:  

@technosaurus,

I'll look at that "int.sh". I'm still considering how to do it.

Concerning "searching", I tend to agree, so I want to make it quite direct when things are specified.
Unfortunately for mainstream puppy, removing "searching" altogether is probably a bit too radical a step.

gyro
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1551
Location: Brisbane, Australia

PostPosted: Mon 20 Jun 2016, 19:49    Post subject:  

@jlst,

How about I setup any interested folk as collaborators to my fork of woof-ce?
Then do a pull-request every so often.

gyro
Back to top
View user's profile Send private message 
jlst

Joined: 23 Nov 2012
Posts: 571

PostPosted: Tue 21 Jun 2016, 09:47    Post subject:  

I'm ok with that
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1551
Location: Brisbane, Australia

PostPosted: Wed 22 Jun 2016, 16:40    Post subject: Fallback when specification fails  

The current "init" tries to be too "friendly" in what it does when a specified partition or file is not found.
If anything is specified and not found, "init" should act as though the file is not present.
It should not fallback to the default file, and use that, as the current "init" tries to do.

Why?
So that you get immediate feedback that the spec is incorrect.
If you're specifying an alternative sfs to test something, and it boots fine. The obvious assumption is that the test sfs is fine.
But if there is a typo in your spec, and "init" used the default sfs instead, then your assumption is incorrect.
You're more likely to notice if the sfs is missing from the boot.

(Of course it also makes the code simpler.)

gyro
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 4208
Location: Kiel,Germany

PostPosted: Wed 22 Jun 2016, 19:25    Post subject:  

unfortunately bloat is necessary .
there are too many possibilities of HW configurations available,
so testing needs done.

I have my own init code to speed up the search.
My init code accepts parameters like sfsload=oldsyle|new that is to load the sfs
and lastly the puppy.sfs and zdrv.sfs ;
and pupmode=X to force a pupmode and if X is something unknown falls back to 5 something like that ; instead editing the init to change 12 to 13 and such .

But I rub fukk installs on pupmode 2 mostly.
I wish you good luck Wink

_________________
«Give me GUI or Death» -- I give you [[Xx]term[inal]] [[Cc]on[s][ole]] .
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal Razz
Back to top
View user's profile Send private message 
greengeek


Joined: 20 Jul 2010
Posts: 5234
Location: Republic of Novo Zelande

PostPosted: Thu 23 Jun 2016, 16:27    Post subject: Re: Fallback when specification fails  

gyro wrote:
If anything is specified and not found, "init" should act as though the file is not present. It should not fallback to the default file, and use that, as the current "init" tries to do.
Why?
So that you get immediate feedback that the spec is incorrect.
Is it possible to include user interaction at this point so that the following occurs?:

- file not found
- tell user file not found
- ask user if they want further searches done or not (in case new user unsure how to proceed and wants to see if anything else CAN automatically be found - so they may end up with a clue where the file actually was)
- ie: no automatic searches performed without at least asking the user.
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1551
Location: Brisbane, Australia

PostPosted: Thu 23 Jun 2016, 17:49    Post subject: Re: Fallback when specification fails  

greengeek wrote:
Is it possible to include user interaction at this point so that the following occurs?
No.
1. With "huge-kernels" there are no kernel modules ordinarily available to "init", so any device requiring kernel modules to work, will not work while "init" is running, this includes some keyboards. (I have one.)
Currently only the savefile/savefolder code in "init" requires keyboard input.
One of the aims of the rewrite is to get the sfs files loaded so that the "initmodules" facility can "insmod" any keyboard required modules before the keyboard is needed.
Adding more keyboard interaction during "init" only makes an already complicated situation more complicated.

2. I don't consider folk who are specifying alternate sfs files via boot parameters to be complete noobies.

gyro
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4841
Location: Blue Springs, MO

PostPosted: Fri 24 Jun 2016, 00:30    Post subject: Re: Fallback when specification fails  

gyro wrote:
One of the aims of the rewrite is to get the sfs files loaded so that the "initmodules" facility can "insmod" any keyboard required modules before the keyboard is needed.
If you need to load kernel modules during init, the kernel is configured wrong. Just change tne CONFIG_XXXX=M to =Y for everything referenced in init - there should be no modules in the initramfs/initrd.
_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
jlst

Joined: 23 Nov 2012
Posts: 571

PostPosted: Fri 24 Jun 2016, 13:17    Post subject:  

That leads us to kernel-kit and the huge kernels already built. When compiling a kernel, one needs to be sure that all (or almost all) modules that have to do with keyboard input are builtin.. if a huge kernel does not comply with this, then it should be deleted immediately...
Back to top
View user's profile Send private message 
jlst

Joined: 23 Nov 2012
Posts: 571

PostPosted: Fri 24 Jun 2016, 19:52    Post subject:  

gyro, watching the logs I see vercmp complains about a wrong syntax... i made sure the busybox vercmp works the same as the standalone app.

This happens when one of the operands is empty, so I wonder if there is something to delete there...
Back to top
View user's profile Send private message 
jlst

Joined: 23 Nov 2012
Posts: 571

PostPosted: Fri 24 Jun 2016, 21:28    Post subject:  

i think we should use the full blkid in the initrd, it's just more robust at everything, but a bit slower too
Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1546

PostPosted: Fri 24 Jun 2016, 21:56    Post subject:  

jlst wrote:
That leads us to kernel-kit and the huge kernels already built. When compiling a kernel, one needs to be sure that all (or almost all) modules that have to do with keyboard input are builtin.. if a huge kernel does not comply with this, then it should be deleted immediately...

Do the templates in kernel-kit/configs_extra comply with this? I think there's 12 of them in there.

edit: Nevermind, I think gyro answered this in the next post.

Last edited by Sailor Enceladus on Fri 24 Jun 2016, 22:03; edited 3 times in total
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 6 [88 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1668s ][ Queries: 14 (0.0210s) ][ GZIP on ]