[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] directory for config files.



Well a while back I came up with a "solution/idea" but was rejected, which
is fine, but is still interesting (I think). (People said was too
complicated)

the folder retrieval is dependant on the name of the kernel itself. And
everything following.. That means:

If in your /c/auto you have mintnp.prg 
It will look for mint.cnf IN /c/mintnp/ folder (same for the xdd etc).

If your /c/auto has minttest.prg for the kernel filename, it will look
into /c/minttest/ 
etc etc
This idea came to me as it was getting annoying to edit my cnf and change
some driver WITHIN the folder (multitos) for different setup.

So one can have several kernel (like I have 4 of them right now (diff
versions)) and one can have like mintx, mintgem, mintsngle.prg whatever...

This was rejected and I understand. Just an idea though...



On Thu, 30 Sep 1999, Thomas wrote:

> On Thu, Sep 30, 1999 at 01:56:41AM +0200, Guido Flohr wrote:
> >I still have no problems with more than one config/driver directory but I
> >*do* have problems with that naming scheme (mint.prg vs. mintnp.prg vs
> >mintvm.prg or what was it). The kernel doesn't need any external file
> >system driver to read that file. It would work and we wouldn't have to
> >explain newbies "well, the `exec' directive only gets executed in the
> >second go while PROTECTION=on/off is only evaluated in the first go" ...
> 
> I want to say, that I fully agree here with Guido. I am using a boot
> selector program (XBOOT) that complains every time I change the Name of the
> MiNT executable, e.g. when I want to enable memory protection and I rename
> mintnp.prg to mint.prg, XBoot complains that mintnp.prg is missing...
> And in a mintboot.cnf, we could also determine where MiNT should look for
> the mint.cnf, so that ./ , mint/ and multitos/ problem would be solved!?!
> 
>  Thothy
> 
>