DragonFly kernel List (threaded) for 2007-08
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
vkernel.conf ?
thread renamed appropriately..
Simon 'corecode' Schubert wrote:
> -1000. getcap is a total misdesign. you can't use colons in values and
> it is not really humanly readable.
bah!
I thinkgetcap is disliked because *termcap* settings are so terse..
Compare /etc/gettytab with /etc/login.conf..
Gettytab is very spartan and not understandable (e.g. what's a :uc: ?),
but /etc/login.conf is very clear.. (oh.. :autodelete=30d: )
I might be wrong about your preference here though..
and yes, the colon thing is a minor limitation.
But the parser is 'built in'..
Unless there is an ini parser in the system I don't know about..
>
> what for do you need that config anyways?
>
I think the general idea (from this and some previous discussions)
is to make vkernels completely config file based.. for example:
$ vkernel [start|stop|reset|check|console|list] [configname|all]
where configname would be an entry in /etc/vkernel.conf with
something like:
configname:\
:memory=32m:\
:vkd0=/path/to/file:\
:vke0=auto,bridge0,10.0.0.1,0xDEADBEEF:\
etc.
or as you prefer:
[configname]
memory=32m
vkd0=/path/to/file
...
Note that the config file entries look just about identical...
A dhcp / named 'C' style config syntax would be my preference from a
user perspective, but definitely not from an implementers perspective..
Similarly, branching the logic for amd's 'fsinfo' parser might
be a good fit user-wise, but would be more work too..
also,
this probably brings up the 'default vkernel installation path' again..
unless 'vkernel' becomes a wrapper program around some kind of
'libexec/vk.configname' mechanism.. which actually sounds worth thinking
about..
- Chris
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]