On Monday, 28 August 2000 at  8:24:50 -0500, Mike Meyer wrote:
> Maxim Sobolev writes:
>> Mike Meyer wrote:
>>>>> Will the system fail to boot if there isn't an empty device.hints
>>>>> file?
>>>> No, it will boot, but some devices (like keyboard, console etc) would not work.
>>>
>>> That's clearly not true - I just removed an empty /boot/device.hints
>>> and rebooted, and all those things work fine. I can believe that such
>>> things won't work if they aren't specified in some hints file, but an
>>> empty /boot/device.hints doesn't do anything more to specify them than
>>> one that isn't there.
>> That's probably because you have hints compiled into your kernel. Try to compile
>> kernel w/o hints and use it with empty/unexistent /boot/device.hints and you will 
>see
>> what I mean.
>
> Well, yeah, I'd expect that. I'm still trying to figure out what
> *good* failing to compile unless there's an empty /boot/device.hints
> does. I mean, if I didn't provide kernel hints, it would make some
> sense if the build process could determine that it was building on the
> machine it was running on.

On Monday, 28 August 2000 at 14:45:23 -0600, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Mike Meyer writes:
>> Maxim Sobolev writes:
>>> Mike Meyer wrote:
>>>
>>>> Donn Miller writes:
>>>>> Mike Meyer wrote:
>>>>>> I do read cvs-all, and I missed it. Not did I find device.hints in the
>>>>>> relevant Makefiles. Can you provide a pointer to details on how
>>>>>> /boot/device.hints is used in the build process, or how having an
>>>>>> empty one keeps you from shooting yourself in the foot?
>>>>> Actually, device.hints isn't used in the build process.
>>>> In that case, why does the kernel build process fail if it doesn't
>>>> exist?
>>> Probably because you have `hints "BLABLA.hints"' line in your kernel config
>>> file.
>>
>> That doesn't really answer the question. Yup, I use
>> GENERIC.hints. That exists. I can see why that not existing would
>> cause problems, but not /boot/device.hints? *Especially* when I'm
>> building a kernel for a different machine?
>
> The build of the kernel isn't forbidden by not having
> /boot/device.hints, just the install.  I just copied my GENERIC.hints
> to /boot/device.hints and things were happy.
>
>> That's clearly not true - I just removed an empty /boot/device.hints
>> and rebooted, and all those things work fine. I can believe that such
>> things won't work if they aren't specified in some hints file, but an
>> empty /boot/device.hints doesn't do anything more to specify them than
>> one that isn't there.
>
> Specifically, the console will not work without hints.  These hints
> can be compiled in or in /boot/device.hints.  You need to have
>
> hint.atkbdc.0.at="isa"
> hint.atkbdc.0.port="0x060"
> hint.atkbd.0.at="atkbdc"
> hint.atkbd.0.irq="1"
> hint.atkbd.0.flags="0x1"
> hint.vga.0.at="isa"
> hint.sc.0.at="isa"
> hint.sc.0.flags="0x100"
>
> At a minimum, but I might be mistaken about that.

At the very least, there appears to be confusion about how to use the
hints.  I can see two conflicting views here:

1.  You must have a /boot/device.hints file, but it may be empty.
2.  You must have a /boot/device.hints file, and it must contain at
    least some entries.

I ran into this same problem yesterday.  I had noticed it in the cvs
mailing list, and I found the first entry in UPDATING.  But it didn't
say what to put in, and I found no other documentation.  Finally John
Baldwin told me to copy my GENERIC.hints, so I did that, and it
worked.  But it seems that we should have some documentation here.  On
the face of it, (1) above seems the most obvious solution.  In that
case, 'make install' shouldn't fail if there's no device.hints file,
it should make one.  If it's (2), it can still copy the MYKERNEL.hints
file.  Which begs the question: when should the hints file be updated?

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to