Re: [MiNT] directory for config files.

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Hi,

On Thu, Sep 23, 1999 at 07:48:00AM +0000, John Blakeley wrote:
> > > avoid confusion. I'm sorry, Guido. I disagree completely with your
> > > example.
> 
> > I never said that I would recommend such a setup.  
> 
> Apologies, Guido. I read it that you did. Sorry.

Sorry, for saying that so harsh.  It wasn't meant that way.  English is
not my native language... ;-)

> This does raise certain questions though.
> 
> Scenario:
> 
> An Atari enthusiast wants to install MiNT. They are not aware of
> SpareMiNT, KGMD, TAF or any other of the distributions that the majority
> of us are familiar with. They just have the 'Multitos' disk that came with
> their Atari. They install this, and in c:\multitos they have an xdd, that,
> for the sake of this example, doesn't work with a 1.15 and later kernel:
> it causes the boot process to hang. This, of course, is not a problem, as
> they are using the Atari-supplied kernel, 1.10 (or something).

Hm, are there any old drivers that will cause a new kernel to hang?  The
other way round (new driver with old kernel) I'm sure that this can happen
but in this case?

> 
> Then they discover 'NutMiNT' - a new FreeMint 1.17 kernel-based
> installation package on the web. They download it to their hard-disk, and
> run 'nutmint.tos', a renamed mint.prg of the kernel, 1.17. This
> nutmint.tos, will load all *.x?? in '.', 'c:\mint' (if it exists) and the
> incompatible xdd in 'c:\multitos'. And nothing! The boot procedure of mint
> fails. They have to reboot. The same thing, over and over again. Now this
> person is not afraid to ask question, so they send an email to the
> mint-list, describing what happens. Some of us are successfully using this
> NutMiNT distribution, and can't understand why it would fail at this
> stage. This newbie, gets dissolusioned(sp?) after a couple of days, and
> just plain gives up, maybe even sells their Milan/Hades, whatever.

The kernel should be a little more verbose here.  It should say what it's
doing:

	Loading device driver /mint/foobar.xdd
	Loading device driver /multitos/barbaz.xdd
	Skipping duplicate driver /multitos/foobar.xdd

> (what a load of waffle, me thinks! <grin>)
> 
> 
> An idea has occurred to me, writing this. What about, if we had a
> compile-time option for the kernel, -DDISTRIBUTION, or something. This, if
> defined, would limit the search path to '.' for mint.cnf and *.x??. This
> would be simplicity itself, to implement into the current kernel. Under
> normal circumstances, this would never be defined and binary distributions
> should never be released with this. But, anyone preparing a distribution,
> could compile with this option. That way they would know for sure what was
> being loaded, blah-de-blah, and the above, highly contrived, but quite
> possible, scenario, would be avoided.

Hm, don't like that.  We already have a whole bunch of different kernels
(68000, 68030, Milan, with or w/o debugging, ...).  Not another one.  A
distribution could just as well check if there are extra directories or
stale drivers and warn or offer the possibility to remove/rename them.

> 
> Then again, if a distribution-maintainer is going to recompile the
> kernel, they could always modify the source so that it only checked '.',
> but that's a lot more hassle, that just adding a #define to the Makefile.
> 
> Thoughts on this, anyone?
> 
> Personally, the search-path does not bother me, but, now with my
> distribution-maintainers hat on, I am bothered by the search paths, and
> would want to control it precisely.

But you have all means to do that.  Simply check the contents of C:\auto,
C:\mint and C:\multitos.  On the kernel side, I think the above proposals
(more verbosity and avoiding duplicate drivers) will also fix things.

Today I think that some people may get very unhappy if we
change the search path.  For the time being I would rather precise the
docs saying that the "auto" location should be reserved for installation
programs, "mint" is the preferred location and "multitos" is deprecated
now and may vanish in the future.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:gufl0000@stud.uni-sb.de