| View previous topic :: View next topic |
| Author |
Message |
ryker
Guru
Joined: 28 May 2003
Posts: 412
Location: Portage, IN
|
 Posted: Sun Mar 11, 2007 3:04 pm Post subject: |
 |
|
I was able to get einit mostly working for me. As everyone says, it is amazingly fast. My main problem right now is that my usb mouse doesn't work, so I can't do anything in kde. I thought I saw someone else had a similar problem, but I can't seem to find it now. Any ideas how I can get my mouse working?
I'm also curious how to get gensplash working, but it boots so fast with einit, it's not really that big of a deal if it doesn't work. 
_________________
Athlon 64 3200+, 80G WD sata hd + 200G IDE, 1G Geil DDR400, MSI K8T Neo
IntelCore2Duo 2.0Ghz MSI laptop,100G SATA hd, 2G RAM |
|
| Back to top |
|
 |
aidanjt
Veteran
Joined: 20 Feb 2005
Posts: 1118
Location: Rep. of Ireland
|
| Posted: Sun Mar 11, 2007 3:04 pm Post subject: |
|
|
I'm still trying to get my head around udev init with baselayout to figure out how it coldplugs usb stuff properly and einit isn't, it does a lot of bash magic.
I screwed udev up a bit adding an extra udev command, I'll keep ya'll posted. My LiveUSB stick is handy for this  |
|
| Back to top |
|
|
jvale
n00b
Joined: 23 Jan 2006
Posts: 74
Location: Porto, Portugal
|
| Posted: Sun Mar 11, 2007 3:52 pm Post subject: |
|
|
| IvanMajhen wrote: | I just tested einit for first time. I can just say WOW. 
Is fbsplash with progress bar working?
And when in kde, shutdown doesn't work. How can i fix this? |
Quoting Magnus, in a post some time ago:
| mdeininger wrote: |
you can modify the command that kdm sends to shut down: edit your kdmrc (something like /usr/kde/3.5/share/config/kdm/kdmrc) and modify thes lines
| Code: |
[Shutdown]
# The command (subject to word splitting) to run to halt the system.
# Default is "/sbin/halt"
#HaltCmd=
# The command (subject to word splitting) to run to reboot the system.
# Default is "/sbin/reboot"
#RebootCmd=
# Whether it is allowed to shut down the system via the global command FiFo.
# Default is false
#AllowFifo=true
# Whether it is allowed to abort active sessions when shutting down the
# system via the global command FiFo.
# Default is true
#AllowFifoNow=false
|
to
| Code: |
[Shutdown]
# The command (subject to word splitting) to run to halt the system.
# Default is "/sbin/halt"
HaltCmd=/sbin/power off
# The command (subject to word splitting) to run to reboot the system.
# Default is "/sbin/reboot"
RebootCmd=/sbin/power reset
# Whether it is allowed to shut down the system via the global command FiFo.
# Default is false
AllowFifo=false
# Whether it is allowed to abort active sessions when shutting down the
# system via the global command FiFo.
# Default is true
#AllowFifoNow=false
|
. (that should at least work in theory. that's how i set it on my box, but i don't use kdm anymore )
|
|
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Sun Mar 11, 2007 4:46 pm Post subject: |
|
|
heh, yes that should work perfectly fine 
then again, if you're using einit-0.16.0, you could also enable the service "initctl", then the commands "shutdown" and "reboot" provided by standard sysvinit will work and so should kdm
about that mouse: maybe you need to load a certain kernel module... /etc/modules.autoload.d/kernel-2.6 is not used by default, although that should be possible (commited a module to do it a while ago).
i've had some issues with udev myself, mostly with device nodes for my nvidia card... maybe something's wrong with the initialisation commands i use, anyone hacking with them should see /lib/einit/einit.xml (or for non-svn versions it's in /etc/einit/einit.xml) (the fstab-entry for /dev contains a script that is run that tries to get udev up...)
i'm really glad it's mostly working with no really evil showstoppers right now, but if you find any, please do keep pointing them out -- can't make it better if i don't know what's broken
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
aidanjt
Veteran
Joined: 20 Feb 2005
Posts: 1118
Location: Rep. of Ireland
|
| Posted: Sun Mar 11, 2007 4:55 pm Post subject: |
|
|
| mdeininger wrote: | heh, yes that should work perfectly fine
then again, if you're using einit-0.16.0, you could also enable the service "initctl", then the commands "shutdown" and "reboot" provided by standard sysvinit will work and so should kdm
about that mouse: maybe you need to load a certain kernel module... /etc/modules.autoload.d/kernel-2.6 is not used by default, although that should be possible (commited a module to do it a while ago).
i've had some issues with udev myself, mostly with device nodes for my nvidia card... maybe something's wrong with the initialisation commands i use, anyone hacking with them should see /lib/einit/einit.xml (or for non-svn versions it's in /etc/einit/einit.xml) (the fstab-entry for /dev contains a script that is run that tries to get udev up...)
i'm really glad it's mostly working with no really evil showstoppers right now, but if you find any, please do keep pointing them out -- can't make it better if i don't know what's broken |
Yeah, I've made some changes to the /dev fstab entry already to match the script provided by udev (in /lib/rcscripts/addons/udev-start.sh), it's not coldplugging my DSL TA but I'm getting there.
Edit: bollocks, modprobing the kernel module locked up my kernel |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Sun Mar 11, 2007 5:03 pm Post subject: |
|
|
| AidanJT wrote: | | Yeah, I've made some changes to the /dev fstab entry already to match the script provided by udev (in /lib/rcscripts/addons/udev-start.sh), it's not coldplugging my DSL TA but I'm getting there. |
if you get it refined to work better, please do post so i can change it in the original file
| AidanJT wrote: | | Edit: bollocks, modprobing the kernel module locked up my kernel |
foo?
yeah some kernel modules like to act up a lot, there's one on my main dev machine for its NIC that will lock up the kernel if it's unloaded... but only if it does *not* have an interface assigned to it, weird thing
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
aidanjt
Veteran
Joined: 20 Feb 2005
Posts: 1118
Location: Rep. of Ireland
|
| Posted: Sun Mar 11, 2007 5:12 pm Post subject: |
|
|
Strange indeed.
Ah, there was one other thing I noticed, I see einit creates a UNIX socket for IPC in /etc/einit-control, any chance of moving it into /etc/einit/ to keep things that wee bit neater? I'm using the einit-0.16.0 ebuild so if you've already done so, due fully ignore as I haven't poked about SVN yet. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Sun Mar 11, 2007 5:14 pm Post subject: |
|
|
| AidanJT wrote: | | Ah, there was one other thing I noticed, I see einit creates a UNIX socket for IPC in /etc/einit-control, any chance of moving it into /etc/einit/ to keep things that wee bit neater? I'm using the einit-0.16.0 ebuild so if you've already done so, due fully ignore as I haven't poked about SVN yet. |
sure, that'll be easy
makes sense too
(wonder why i haven't done that when i first put it in place, it really doesn't make much sense?)
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
aidanjt
Veteran
Joined: 20 Feb 2005
Posts: 1118
Location: Rep. of Ireland
|
| Posted: Sun Mar 11, 2007 7:19 pm Post subject: |
|
|
This is what I have so far, I haven't managed to get it to coldplug my cxacru driver yet yet, but it boots fine, I thought I'd share what I have to see if it'll help, I added the before-mount to deal with that pesky problem with /dev/console being missing on the root partition and strip off all that udevd pipeage, wont help if the root partition is mounted read only though.
| Code: |
<node mountpoint="/dev" fs="tmpfs" device="udev"
manager="/sbin/udevd"
before-mount='if test ! -c /dev/console; then mknod /dev/console c 5 1 -m 0600; fi;'
after-mount='
echo "feedback|notice|seeding /dev";
if test -d /lib/udev/devices; then cp -a /lib/udev/devices/* /dev; fi;
ln -snf /proc/self/fd /dev/fd;
ln -snf fd/0 /dev/stdin;
ln -snf fd/1 /dev/stdout;
ln -snf fd/2 /dev/stderr;
if test -e /proc/kcore; then ln -snf /proc/kcore /dev/core; fi;
if test ! -e /dev/console; then mknod /dev/console c 5 1 -m 0600; fi;
echo "feedback|notice|creating device nodes";
/sbin/udevd --daemon;
/sbin/udevtrigger --attr-match=dev;
/sbin/udevsettle --timeout=30;' />
|
It's amazing how non-existent udev documentation is regarding the system initialisation process 
EDIT: minor change to make udev look like it's mounted with udev instead of tmpfs
Still have yet to make any progress with the coldplugging |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Tue Mar 13, 2007 10:49 am Post subject: |
|
|
not sure what we might do here as well... udev's a bitch and yeah, somehow the docs about how to make it init properly are missing completely
in the meantime, i kind of "fixed" the alsa module, so for all that did not set up their /etc/modules.d/alsa file, it will do the same auto-detecting as gentoo does, which means that alsa should now "just work" if it did in gentoo
also i moved einit's primary output to tty9, re-activated vt1 with a tty line, and made the setfont module run *before* the tty module (else it would blank all tty's login: requests on my box ).
gotta admit, setting a nice font on the ttys really *is* nice, i had completely forgotten about that, thanks for reminding me
oh, the default swap line in local.xml has been removed, and the one in einit.xml sets the -a parameter to swapon, which means that the swap devices in fstab will be used unless you override it with your own swap device in local.xml
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
aidanjt
Veteran
Joined: 20 Feb 2005
Posts: 1118
Location: Rep. of Ireland
|
| Posted: Tue Mar 13, 2007 12:23 pm Post subject: |
|
|
| mdeininger wrote: | not sure what we might do here as well... udev's a bitch and yeah, somehow the docs about how to make it init properly are missing completely
in the meantime, i kind of "fixed" the alsa module, so for all that did not set up their /etc/modules.d/alsa file, it will do the same auto-detecting as gentoo does, which means that alsa should now "just work" if it did in gentoo
also i moved einit's primary output to tty9, re-activated vt1 with a tty line, and made the setfont module run *before* the tty module (else it would blank all tty's login: requests on my box ).
gotta admit, setting a nice font on the ttys really *is* nice, i had completely forgotten about that, thanks for reminding me
oh, the default swap line in local.xml has been removed, and the one in einit.xml sets the -a parameter to swapon, which means that the swap devices in fstab will be used unless you override it with your own swap device in local.xml |
Nice, the whole thing is shaping up great, thanks for shifting the einit screen to tty9, twas a bit funny having to jump into tty2 to login  |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Wed Mar 14, 2007 12:16 am Post subject: |
|
|
*g* yeah, i can kind of relate to that
well, another change: i moved /etc/einit-control to /etc/einit/control to keep things cleaner and in line. i'm also rewriting some functions in assembly (now guess why i posted that request for help on OTW ), because i noticed that >35% of the time einit is doing something, it's done by strcmp() (so i'm trying to write a new function to match things... and another replacement for strlen() while i'm at it). i was able to cut roughly 1/19th of the instructions used in sandbox mode on amd64, so i definitely think there's some good room for improvement that way
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
aidanjt
Veteran
Joined: 20 Feb 2005
Posts: 1118
Location: Rep. of Ireland
|
| Posted: Wed Mar 14, 2007 12:18 am Post subject: |
|
|
| Nice, now I just need a C2D |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Wed Mar 14, 2007 12:46 am Post subject: |
|
|
| AidanJT wrote: | | Nice, now I just need a C2D |
i'll port that assembly to the x86 version soon enough anyway, it's not much of a biggie (only need to rename some registers), just want the code to be actually smaller before i do so
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
aidanjt
Veteran
Joined: 20 Feb 2005
Posts: 1118
Location: Rep. of Ireland
|
| Posted: Wed Mar 14, 2007 12:53 am Post subject: |
|
|
| mdeininger wrote: | | AidanJT wrote: | | Nice, now I just need a C2D |
i'll port that assembly to the x86 version soon enough anyway, it's not much of a biggie (only need to rename some registers), just want the code to be actually smaller before i do so |
No need to hurry for me, I'm gonna replace this P4 anyway, it's showing it's age, upgrades are too expensive and such
I noticed in SVN that you have a C++ branch, is it something you've been considering doing? |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Wed Mar 14, 2007 1:05 am Post subject: |
|
|
| AidanJT wrote: | | mdeininger wrote: | | AidanJT wrote: | | Nice, now I just need a C2D |
i'll port that assembly to the x86 version soon enough anyway, it's not much of a biggie (only need to rename some registers), just want the code to be actually smaller before i do so |
No need to hurry for me, I'm gonna replace this P4 anyway, it's showing it's age, upgrades are too expensive and such |
heh, had that a while ago and decided on getting a new athlon64-x2. its benefits over a c2d are argueable, but one thing's for sure: upgrades and replacement parts are cheaper
| AidanJT wrote: | | I noticed in SVN that you have a C++ branch, is it something you've been considering doing? |
kind of, there's been a feature request to implement exceptions in einit, however the project is obviously plain C so there just plain aren't any exceptions i could implement since those are only available in C++. the request shifted towards compatibility with C++ though, and I figured it'd probably be nice to write modules in that. I still think it'd be a bad idea to write a low-level program like einit in C++, but writing modules in that would be cool with me, thus i'm trying to create a reference library that would only need to be linked against to make it really easy for interested persons to write binary modules in that
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Wed Mar 14, 2007 1:41 am Post subject: |
|
|
i was thinking about that little argument about initng and einit and runnit a short while ago and predatorfreak make a good point about einit not really being "minimalistic" and about the size of the executable.... then I started thinking about all of the "modules" which really dont make sense to be modules in the first place.... im talking about everthing einit related thats not build directly into einit.... people are either going to need a feature on a system or not so anything "extra" should be a configurable option at build time (and then enabled by useflag for gentoo ebuilds)... that way people can select and little or as much as they want
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Wed Mar 14, 2007 8:21 am Post subject: |
|
|
| rmh3093 wrote: | | i was thinking about that little argument about initng and einit and runnit a short while ago and predatorfreak make a good point about einit not really being "minimalistic" and about the size of the executable.... then I started thinking about all of the "modules" which really dont make sense to be modules in the first place.... im talking about everthing einit related thats not build directly into einit.... people are either going to need a feature on a system or not so anything "extra" should be a configurable option at build time (and then enabled by useflag for gentoo ebuilds)... that way people can select and little or as much as they want |
i admit he's got a point, but doing it through the shared libraries loader allows for this... to completely disable modules that a user does not use or intend to use, there's this configuration option:
| Code: |
<load pattern-allow=".*\.so" pattern-disallow="^compatibility.*" />
|
the pattern-disallow="" is applied to all binary modules before they're loaded, allowing anyone to simply skip those modules that they do not need.
predatorfreak contacted me on IM later that evening and proposed some good things. one good thing about the dynamic loader approach is that i could remove all the modules that aren't being used anymore from memory, thus decreasing einit's memory profile. and while i'm sure you noticed that i made other parts of the core external, they can still be built into the core, and i'm trying to get the same done for all the other modules, so that static linking's finally gonna become an option
a disallow pattern is obviously not gonna help with the size of the program, but compiling modules into the core might, and making things a little more configurable should help here as well. on the other hand... being able to completely unload the modules would still be nice... guess it's one of those things that a user will have to decide on...
you were right earlier, we could probably use a variable in make.conf for that. or two (for deciding which are built in and which are built as modules)
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Wed Mar 14, 2007 12:00 pm Post subject: |
|
|
| mdeininger wrote: | | rmh3093 wrote: | | i was thinking about that little argument about initng and einit and runnit a short while ago and predatorfreak make a good point about einit not really being "minimalistic" and about the size of the executable.... then I started thinking about all of the "modules" which really dont make sense to be modules in the first place.... im talking about everthing einit related thats not build directly into einit.... people are either going to need a feature on a system or not so anything "extra" should be a configurable option at build time (and then enabled by useflag for gentoo ebuilds)... that way people can select and little or as much as they want |
i admit he's got a point, but doing it through the shared libraries loader allows for this... to completely disable modules that a user does not use or intend to use, there's this configuration option:
| Code: |
<load pattern-allow=".*\.so" pattern-disallow="^compatibility.*" />
|
the pattern-disallow="" is applied to all binary modules before they're loaded, allowing anyone to simply skip those modules that they do not need.
predatorfreak contacted me on IM later that evening and proposed some good things. one good thing about the dynamic loader approach is that i could remove all the modules that aren't being used anymore from memory, thus decreasing einit's memory profile. and while i'm sure you noticed that i made other parts of the core external, they can still be built into the core, and i'm trying to get the same done for all the other modules, so that static linking's finally gonna become an option
a disallow pattern is obviously not gonna help with the size of the program, but compiling modules into the core might, and making things a little more configurable should help here as well. on the other hand... being able to completely unload the modules would still be nice... guess it's one of those things that a user will have to decide on...
you were right earlier, we could probably use a variable in make.conf for that. or two (for deciding which are built in and which are built as modules) |
but no user will ever really need to dynamically load/unload modules for their init system like they do for a kernel, it would be one thing if the einit core was very tiny and smart and loaded/unload modules on the fly, but that would propably add extra overhead in smartness for something thats not even needed
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
aidanjt
Veteran
Joined: 20 Feb 2005
Posts: 1118
Location: Rep. of Ireland
|
| Posted: Wed Mar 14, 2007 12:17 pm Post subject: |
|
|
| rmh3093 wrote: | | but no user will ever really need to dynamically load/unload modules for their init system like they do for a kernel, it would be one thing if the einit core was very tiny and smart and loaded/unload modules on the fly, but that would propably add extra overhead in smartness for something thats not even needed |
A dynamic 'smart' loader could be made as a module for opt-in/opt-out at compile time perhaps? |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Wed Mar 14, 2007 1:42 pm Post subject: |
|
|
| AidanJT wrote: | | rmh3093 wrote: | | but no user will ever really need to dynamically load/unload modules for their init system like they do for a kernel, it would be one thing if the einit core was very tiny and smart and loaded/unload modules on the fly, but that would propably add extra overhead in smartness for something thats not even needed |
A dynamic 'smart' loader could be made as a module for opt-in/opt-out at compile time perhaps? |
but what im saying is that, when you install an init system on your box (be it a server, or a desktop, or pda) you already know exactly what you need it to do (for the most part) so you build what you need once and call it a day, if you learn of something else you want; recompile, einit isnt that big.... its not like you are gonna want the fbsplash module on tuesdays and thursdays and on every other day you wan the evas splash... get what im saying?
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
aidanjt
Veteran
Joined: 20 Feb 2005
Posts: 1118
Location: Rep. of Ireland
|
| Posted: Wed Mar 14, 2007 1:52 pm Post subject: |
|
|
| rmh3093 wrote: | | AidanJT wrote: | | rmh3093 wrote: | | but no user will ever really need to dynamically load/unload modules for their init system like they do for a kernel, it would be one thing if the einit core was very tiny and smart and loaded/unload modules on the fly, but that would propably add extra overhead in smartness for something thats not even needed |
A dynamic 'smart' loader could be made as a module for opt-in/opt-out at compile time perhaps? |
but what im saying is that, when you install an init system on your box (be it a server, or a desktop, or pda) you already know exactly what you need it to do (for the most part) so you build what you need once and call it a day, if you learn of something else you want; recompile, einit isnt that big.... its not like you are gonna want the fbsplash module on tuesdays and thursdays and on every other day you wan the evas splash... get what im saying? |
Sure do, I don't see much point in it myself but I may be the exception, not the rule for all I know |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Wed Mar 14, 2007 4:38 pm Post subject: |
|
|
| rmh3093 wrote: | | AidanJT wrote: | | rmh3093 wrote: | | but no user will ever really need to dynamically load/unload modules for their init system like they do for a kernel, it would be one thing if the einit core was very tiny and smart and loaded/unload modules on the fly, but that would propably add extra overhead in smartness for something thats not even needed |
A dynamic 'smart' loader could be made as a module for opt-in/opt-out at compile time perhaps? |
but what im saying is that, when you install an init system on your box (be it a server, or a desktop, or pda) you already know exactly what you need it to do (for the most part) so you build what you need once and call it a day, if you learn of something else you want; recompile, einit isnt that big.... its not like you are gonna want the fbsplash module on tuesdays and thursdays and on every other day you wan the evas splash... get what im saying? |
sure do and that's perfectly sane. the dynamic loader/unloader would only come in handy on devices with seriously limited memory resources where unloading some code could actually help.
guess the best would be getting the build system a bit up to shape so that we can use a simple variable in the user's make.conf to decide what we're going to need and what we don't, like you suggested earlier.
if everything could be compiled in, we could even throw out the module loader code if so desired (although that could get a bitch with addon modules, still it'd be an option )
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Wed Mar 14, 2007 4:43 pm Post subject: |
|
|
| mdeininger wrote: | | if everything could be compiled in, we could even throw out the module loader code if so desired (although that could get a bitch with addon modules, still it'd be an option ) |
who is actually going to write an addon module? and if someone were to write and "addon" it would be just as much work to to build an exernal mod as it would be to make a patch against einit-core
EDIT: getting rid of the modular aspect of einit would allow for a static build to work also
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Wed Mar 14, 2007 5:15 pm Post subject: |
|
|
| rmh3093 wrote: | | who is actually going to write an addon module? and if someone were to write and "addon" it would be just as much work to to build an exernal mod as it would be to make a patch against einit-core |
good point... but some things can't be done as a patch against the core (writing things in C++ for example). also, some things are just more convenient as an external module (the devel stuff for example), and writing them isn't thaa~t hard really (see the modules/gentoo sources.). i suppose it's just a nice option to keep
| rmh3093 wrote: | | EDIT: getting rid of the modular aspect of einit would allow for a static build to work also |
that's certainly true, loading modules that need things from the core just plain won't work if the core is linked statically, and the latter could be *really* handy =)
best to go for the variable-approach in make.conf + a use-flag to enable/disable the module loader code
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
|
|
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
|
|
Unsupported Software
