Invisible <voi### [at] devnull> wrote:
> Ah yes, but in Unix land, a device driver is counted as part of the 
> kernel. ;-)

  There are many pros in monolithic kernels. Of course there are cons,
but many people believe that the pros outweight the cons in this case.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Also: autoconf exists. Need I say more?

  Autoconf exists because not all systems have the same tools or libraries
installed, nor all systems have the same versions of those tools/libraries.

  Autoconf also exists because computer architectures are different.
For instance, some architectures may be little-endian while others are
big-endian. Some architectures may be 32-bit while others are 64-bit.

  Portability is a key feature of unix-like systems.

-- 
                                                          - Warp

Post a reply to this message

> Also: autoconf exists. Need I say more?

When trying to compile POV-Ray for the iPod touch, I had trouble with 
two libraries. JPEG, which used a very old version of autoconf, and 
TIFF, which used a half-assed written-by-hand configure script.

Post a reply to this message

> In what universe is this a "simple tool" with "well defined inputs and 
> outputs"?

ls is a good example of a program that *doesn't* have well-defined 
outputs, in the sense that scripts should never rely on parsing ls 
output. ls is supposed to have *human-readable* output.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Ah yes, but in Unix land, a device driver is counted as part of the 
>> kernel. ;-)
> 
>   There are many pros in monolithic kernels. Of course there are cons,
> but many people believe that the pros outweight the cons in this case.

I just prefer being able to add new drivers without having to recompile 
the kernel and reboot the machine - but that's just me...

OOC, what are the benefits?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:

>   Autoconf exists because not all systems have the same tools or libraries
> installed, nor all systems have the same versions of those tools/libraries.

As far as I can tell, autoconf exists because some systems use BSD awk 
and others use GNU awk, and the two aren't precisely compatible. 
Multiply this by the 50,000 other tiny utilities you may or may not need 
to set up this program and you have a configuration nightmare so bad it 
requires an automated tool to make things remotely tractable.

And it seems to me that most of this has happened because the entire 
system has been poked and prodded by so many different people over time 
that you now have a huge tangled mass of different implementations all 
of which are only semi-compatible.

>   Autoconf also exists because computer architectures are different.
> For instance, some architectures may be little-endian while others are
> big-endian. Some architectures may be 32-bit while others are 64-bit.

Shouldn't the compiler be dealing with those issues?

>   Portability is a key feature of unix-like systems.

That I don't have a problem with... ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> Warp wrote:
>>   Autoconf also exists because computer architectures are different.
>> For instance, some architectures may be little-endian while others are
>> big-endian. Some architectures may be 32-bit while others are 64-bit.
> 
> Shouldn't the compiler be dealing with those issues?

No. If the compiler "dealt" with little endian and big endian, by making 
the C code always see one or the other, it would make the other 
architecture much slower.

Also, the C standard only mentions minimum sizes for data types. A 
compliant C implementation may have 64-bit bytes if it wants to.

Post a reply to this message

>> Shouldn't the compiler be dealing with those issues?
> 
> No. If the compiler "dealt" with little endian and big endian, by making 
> the C code always see one or the other, it would make the other 
> architecture much slower.

What I meant was, shouldn't the programmer be able to just write their 
program, and let the compiler generate the correct code depending on the 
actual processor architecture?

But then, since C is little more than semi-portable machine code, I 
guess that would be quite hard to do.

> Also, the C standard only mentions minimum sizes for data types. A 
> compliant C implementation may have 64-bit bytes if it wants to.

IOW, the C standard is insane. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>> Shouldn't the compiler be dealing with those issues?
>>
>> No. If the compiler "dealt" with little endian and big endian, by 
>> making the C code always see one or the other, it would make the other 
>> architecture much slower.
> 
> What I meant was, shouldn't the programmer be able to just write their 
> program, and let the compiler generate the correct code depending on the 
> actual processor architecture?
> 
> But then, since C is little more than semi-portable machine code, I 
> guess that would be quite hard to do.

Of course there is a lot of code that can be written without caring 
about endianness. In which case you wouldn't tell autoconf to do that check.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I just prefer being able to add new drivers without having to recompile 
> the kernel and reboot the machine - but that's just me...

  I have never had to recompile the kernel or reboot the machine because
of requiring a new driver.

  man modprobe

> OOC, what are the benefits?

  For example, the interfaces and protocols between the kernel and the
drivers can be modified easily without having to worry about backwards
compatibility. If an existing interface or protocol results to be a bad
design choice, or it results to have some inefficiencies in a newer
architecture, they can all be changed without problems. Basically, the
kernel is not burdened with backwards compatibility issues with regard
to drivers.

-- 
                                                          - Warp

Post a reply to this message