Sam Ravnborg wrote:
>So I would suggest:
>
>Config.conf<= Main entry in any directory
>sensible-name.conf <= Any group of related files
>
>ls *.conf list all configuration files.
>ls rrunner*list all files spcific for rrunner
>
I really like this. It's just so intuative
Hi,
On Wed, 9 Oct 2002, Jeff Garzik wrote:
> Which implies that the equivalent of "source drivers/net/Config*"
> (wildcarding) in Roman's system would be useful. Or maybe "source
> drivers/net" and it knows that when given a directory it should scan for
> all Config* files in that dir.
This ma
On Wed, Oct 09, 2002 at 12:28:44PM -0700, Randy.Dunlap wrote:
>
> The kernel would still have the text-mode configurator.
The way I read the original post by Christoph Hellwig - nope.
If the kernel config library is outside the kernel then the
text-mode versions will fail as well.
Recall that the
On Wed, Oct 09, 2002 at 11:47:16AM -0700, Linus Torvalds wrote:
>
> On Wed, 9 Oct 2002, Sam Ravnborg wrote:
> >
> > ls rrunner*
> > should show me not only the implementation [.c + .h] but also
> > the configuration.
>
> I agree with you, but only if we _always_ have one config file per driver.
[Roman Zippel]
> The problem is that the config syntax will continue to evolve and
> currently I prefer to keep the library close to the matching config
> files.
> I think I can keep the basic structure constant, but new options will be
> added, so IMO it's more likely that a front end works with
On Wed, 9 Oct 2002, Sam Ravnborg wrote:
>
> ls rrunner*
> should show me not only the implementation [.c + .h] but also
> the configuration.
I agree with you, but only if we _always_ have one config file per driver.
Which is not necessarily the wrong thing to do.
But as long as most drivers
Hi,
On Wed, 9 Oct 2002, Christoph Hellwig wrote:
> Why don't you just separate the library from the kernel at all, making
> it a similar package. We depend on a few external, kernel-specific
> packages anyway, and depending on libkconfig wouldn't make the situation
> worse.
The problem is that
On Wed, Oct 09, 2002 at 10:37:47AM -0700, Linus Torvalds wrote:
> However, I disagree with the naming - I'd rather have one common name for
> the "main" directory entry than have magic rules like "basename of the
> directory capitalized". I don't want to have to search for it.
OK, see your point
On Wed, 9 Oct 2002, Sam Ravnborg wrote:
>
> Another suggestion about naming:
> Take for example drivers/net:
> cat Config.* | wc => 2149 lines
>
> A bit a structure could be needed here.
> Net.conf <= Name equals directory with upper-case first letter
> - Cover the whole directory, and e
On Wed, Oct 09, 2002 at 02:01:50PM +0200, Roman Zippel wrote:
> On Tue, 8 Oct 2002, Linus Torvalds wrote:
> > Some things made me go eww (but on the whole details):
> >
> > - I'd prefer the Config.in name, since this has nothing to do with
> >building, and everything to do with configuration
On Wed, Oct 09, 2002 at 06:29:03PM +0200, Roman Zippel wrote:
> Hi,
>
> On Wed, 9 Oct 2002, Randy.Dunlap wrote:
>
> > So I think that you and Roman are close to agreement, when Roman
> > has the library backend ready. Of course someone needs to do a
> > "reference implementation" with it also,
Hi,
On Wed, 9 Oct 2002, Randy.Dunlap wrote:
> So I think that you and Roman are close to agreement, when Roman
> has the library backend ready. Of course someone needs to do a
> "reference implementation" with it also, but it doesn't need to
> ship with the kernel.
We ship BK documentation, so
Hi,
On Wed, 9 Oct 2002, J.A. Magallon wrote:
> >stick with TCL/TK, like xconfig currently uses ?
> >or is it not sufficient? or just too ugly?
> >
>
> What is linux kernel conf written in ?
> - perl: use perl-gtk (I think there is also a perl-qt)
> - python: use py-gtk...
>
> Use whatever the l
On Wed, 9 Oct 2002, Randy.Dunlap wrote:
>
> stick with TCL/TK, like xconfig currently uses ?
Too ugly. I actually think QT is a fine choice, I just suspect that it's
going to cause political issues.
My favourite approach by far is to actually not ship anything graphical
with the kernel at all
Hi,
On Thu, 10 Oct 2002, Brendan J Simon wrote:
> As you can see there are soo many guis to choose/use and everyone
> has there favourite. I suggest that the real work be done outside of
> the GUI program. ie. seperate GUI and application guts as much as
> possible. I would use python as
Roman Zippel wrote:
>>But the fact that xconfig depends on QT is going to make some people hate
>>it.
>>
>>
>This should be rather easily fixable, but it has to be done by someone who
>is more familiar with whatever prefered toolkit. I'm familiar with QT and
>it's absolutely great to get qu
Roman Zippel wrote:
>>Well, my basic preference is
>>
>>* something other than Config.new (the original name in your config system)
>>* something other than Config.in
>>
>>I think it is a mistake to name a totally different format the same name
>>as an older format... even "config.in" would be
Hi,
On Wed, 9 Oct 2002, Jeff Garzik wrote:
> Well, my basic preference is
>
> * something other than Config.new (the original name in your config system)
> * something other than Config.in
>
> I think it is a mistake to name a totally different format the same name
> as an older format... even
Hi,
On Tue, 8 Oct 2002, Linus Torvalds wrote:
> I'm not super-excited about this, partly because of the brouhaha last time
> around on this issue.
>
> This has reasonably distributed config files, and puts the help with the
> config entry where it belongs. Good. It also makes do with just standa
"Randy.Dunlap" wrote:
>
> Is there a simple, clean way to assign one tristate value to
> another one? Instead of having to do something like:
>
> if [ "$CONFIG_PARPORT_PC" = "y" ]; then
> define_tristate CONFIG_PARPORT_PC_CML1 y
> else
> if [ "$CONFIG_PARPORT_PC" = "m" ]
20 matches
Mail list logo
