[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Sysinst GSOC project
My name is Zach Wegner. I am 20 years old, and I attend Austin
Community College in Austin, TX. I have been selected for the Google
Summer of Code to help out the NetBSD project. I've been using NetBSD
for several years, and I am excited to become a part of the community.
My project is based on a suggestion by Tim Rightnour, who is also my
mentor. It is to create a file format that can fully specify an
installation, and then split sysinst into a front and back end that
communicate through the file. I.e., you run sysinst with something
like the current interface, but instead of installing, it only creates
the file and then runs the back end once it is done. I am very glad to
be doing this project, and I hope that it succeeds in its goals.
I have discussed some various ideas for the project with Tim, as well
as some other NetBSD guys within the Google application page. It seems
that sysinst is a very volatile subject, and I must stress that I have
both limited time and limited abilities. It is beyond the scope of the
project to completely rewrite sysinst, so most of the code will have
to remain the same. One subject discussed on my application is
language. Apparently many people would like sysinst to be in a
language other than C. While some of the arguments make sense, I just
can't do that. So sorry about that in advance.
The most important part of this project is the file format. What I am
wanting in this format is to be easily readable and editable by
humans, as well as being very flexible. Because of this, I think it
would be best to use a very simple, sh script-like format. I have an
example file that I set up:
There are some missing parts, and I have since noticed that the
slashes are kind of ambiguous, being used for options and directories.
I'm thinking of maybe replacing the option slashes with ?s. If anybody
has any really serious, super-critical reason that this format is bad,
or any little suggestions about the finer points of the syntax, please
say so. But again, I don't have the time to implement a very
complicated parser, and I think the sample format should handle the
task well, so I'd prefer that we don't have a flamewar over this.
I also have some little add-ons that I might be able to add if I get
any time. I'll just write them down here, so that people don't suggest
-Supporting customized sets
-Supporting lists of pkgsrc packages to be installed after the main installation
-Cleaning up the front end to make it a bit more user friendly
-Making a type of conditional logic available, where statements in the
configuration file could give instructions like "Install the
GENERIC_MP kernel if there is more than one processor" or "Install the
GENERIC_TINY kernel if there is less than 10GB disk space".
If there are any other suggestions for extras, feel free. I probably
won't get a chance to do much, but all of them can be done afterwards,
possibly by me. This project will need some help from others, in
particular platform-specific testing and menu translation. I will
contact this list when the time comes.
So in conclusion, this is a pretty basic but important project. The
configuration file will be usable for a long time to come, and people
can write brand new front ends and back ends in whatever language they
choose, interfacing them through the file. I hope I don't sound snobby
or inflexible; I am just a student doing a summer project though. But
anyways, I am looking forward to being a part of your community for
the summer and a long time after that.
Main Index |
Thread Index |