POV-Ray : Newsgroups : povray.off-topic : Linux & drivers Server Time
7 Sep 2024 09:20:20 EDT (-0400)
  Linux & drivers (Message 31 to 40 of 43)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 3 Messages >>>
From: Orchid XP v8
Subject: Re: Linux & drivers
Date: 5 Sep 2008 13:44:12
Message: <48c16fec$1@news.povray.org>
>> The boot sector is really only part of one sector. That doesn't seem 
>> like enough room to write code to find NTLDR or whatever the second 
>> step of Linux boot code is (GRUB I assume, or LILO). Especially given 
>> the wide range of partition types and RAID types a boot partition is 
>> allowed to be on in Linux.
>>
>> How does it fit enough of the file system code into the boot mechanism 
>> to find the files it needs? Is there something special, such that 
>> (say) copying the file to a different place on the disk would keep 
>> things from booting?
> 
> 
> http://www.gnu.org/software/grub/manual/html_node/Bootstrap-tricks.html
> http://www.gnu.org/software/grub/manual/html_node/Images.html
> 
> I know from experience that moving stuff around on the boot partition 
> can break GRUB.

So the location of the real meat is hard-coded into the MBR. Neat...

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


Post a reply to this message

From: Orchid XP v8
Subject: Re: Linux & drivers
Date: 5 Sep 2008 13:46:14
Message: <48c17066$1@news.povray.org>
>> ("Disassembled"? As in, they reverse-engineered a drives from the 
>> Windoze version?)
> 
> The Linux version actually.
> 
> http://kerneltrap.org/node/1606

Ah. So there *is* a Linux driver, the guys just dislike closed-source 
drivers, so they wrote their own?

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


Post a reply to this message

From: Orchid XP v8
Subject: Re: Linux & drivers
Date: 5 Sep 2008 13:49:19
Message: <48c1711f$1@news.povray.org>
>> My understanding is that Linux and NTFS still aren't the best of
>> friends.
> 
> ntfs-3g solves those issues.

Several programs claim to "solve" these issues - with varying degrees of 
safety warnings. ;-)

(There are kernel NTFS drivers, there's a gizmo that loads NTFS.SYS from 
your Windoze partition and uses that, there are read-only NTFS drivers, 
and so on and so forth.)

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


Post a reply to this message

From: Fredrik Eriksson
Subject: Re: Linux & drivers
Date: 5 Sep 2008 13:53:19
Message: <op.ug0ry5xf7bxctx@e6600>
On Fri, 05 Sep 2008 19:46:19 +0200, Orchid XP v8 <voi### [at] devnull> wrote:
>>  The Linux version actually.
>>  http://kerneltrap.org/node/1606
>
> Ah. So there *is* a Linux driver, the guys just dislike closed-source  
> drivers, so they wrote their own?

Presumably, though I do not actually know their motives.

Eventually nVidia started contributing to forcedeth, and a couple of years  
ago they dropped their own driver.


-- 
FE


Post a reply to this message

From: Tom Austin
Subject: Re: Linux & drivers
Date: 5 Sep 2008 14:56:02
Message: <48c180c2$1@news.povray.org>
Orchid XP v8 wrote:
>>> The boot sector is really only part of one sector. That doesn't seem 
>>> like enough room to write code to find NTLDR or whatever the second 
>>> step of Linux boot code is (GRUB I assume, or LILO). Especially given 
>>> the wide range of partition types and RAID types a boot partition is 
>>> allowed to be on in Linux.
>>>
>>> How does it fit enough of the file system code into the boot 
>>> mechanism to find the files it needs? Is there something special, 
>>> such that (say) copying the file to a different place on the disk 
>>> would keep things from booting?
>>
>>
>> http://www.gnu.org/software/grub/manual/html_node/Bootstrap-tricks.html
>> http://www.gnu.org/software/grub/manual/html_node/Images.html
>>
>> I know from experience that moving stuff around on the boot partition 
>> can break GRUB.
> 
> So the location of the real meat is hard-coded into the MBR. Neat...
> 


He beat me to it.

Yes, the MBR's job is only to load the real boot code.


I've never dug enough into it, but I've always been interested in what 
calls the MBR has to make to load sectors and what not.

Those are calls that I could have access to to make my own boot junk.

I wish I had more time.....



Tom


Post a reply to this message

From: Fredrik Eriksson
Subject: Re: Linux & drivers
Date: 5 Sep 2008 15:21:26
Message: <op.ug0v10hh7bxctx@e6600>
On Fri, 05 Sep 2008 20:56:01 +0200, Tom Austin <taustin> wrote:
> I've never dug enough into it, but I've always been interested in what  
> calls the MBR has to make to load sectors and what not.

http://en.wikipedia.org/wiki/INT_13#INT_13h_AH.3D02h:_Read_Sectors_From_Drive



-- 
FE


Post a reply to this message

From: Orchid XP v8
Subject: Re: Linux & drivers
Date: 5 Sep 2008 16:58:51
Message: <48c19d8b$1@news.povray.org>
>> I've never dug enough into it, but I've always been interested in what 
>> calls the MBR has to make to load sectors and what not.
> 
> http://en.wikipedia.org/wiki/INT_13#INT_13h_AH.3D02h:_Read_Sectors_From_Drive 

Well, yeah, those are the BIOS calls to read sectors from a disk while 
in real mode. But then, once you've grabbed enough blocks from disk in 
real mode *then* you can worry about entering protected mode and 
initialising a real filesystem driver, etc.

BTW, I believe Grub supports booting *any* OS that complies with a set 
of simple guidelines. It isn't just limited to booting Linux. (Although 
it won't boot Windoze - but it can call the Windoze bootloader 
automatically.)

And yes, *I* wish I had more time...!

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


Post a reply to this message

From: gregjohn
Subject: Re: Linux & drivers
Date: 5 Sep 2008 18:40:00
Message: <web.48c1b4247002093234d207310@news.povray.org>
Ahem.  So did more than one person try out "some" live CD's and found several
wanting as far as hardware recognition and drivers?!?!!?

Please write up reviews on your blogs! Let the world know!  Linux distros, even
if they are free, are still in a "marketplace" for users.


Post a reply to this message

From: Jim Henderson
Subject: Re: Linux & drivers
Date: 5 Sep 2008 18:41:08
Message: <48c1b584$1@news.povray.org>
On Fri, 05 Sep 2008 18:49:25 +0100, Orchid XP v8 wrote:

>>> My understanding is that Linux and NTFS still aren't the best of
>>> friends.
>> 
>> ntfs-3g solves those issues.
> 
> Several programs claim to "solve" these issues - with varying degrees of
> safety warnings. ;-)
> 
> (There are kernel NTFS drivers, there's a gizmo that loads NTFS.SYS from
> your Windoze partition and uses that, there are read-only NTFS drivers,
> and so on and so forth.)

ntfs-3g is what uses ntfs.sys - and that one is very stable and usable.  
I don't know that it comes with a bunch of warnings, but of course using 
closed code with Linux is going to get people to give "warnings" about 
the difficulty in solving problems should they arise.

But there's *always* risk to using ntfs.sys even with Windows - things 
can go wrong even in a native Windows environment.

Either that, or I imagined the gradual corruption on a coworkers machine 
a few weeks ago. :-)

Jim

Jim


Post a reply to this message

From: Darren New
Subject: Re: Linux & drivers
Date: 6 Sep 2008 00:34:02
Message: <48c2083a$1@news.povray.org>
Jim Henderson wrote:
> ntfs-3g is what uses ntfs.sys - and that one is very stable and usable.  

Is that how it works? That's rather ... baroque. I'm going to have to 
laugh next time someone tells me that having the source code is 
necessary to understand how something works. :-)

> But there's *always* risk to using ntfs.sys even with Windows - things 
> can go wrong even in a native Windows environment.

What surprises me is that there's anything on the file system that can 
grow without bound. But as I understand it, at least the security 
descriptors (i.e., the ACLs) can get put in a hash table and never 
removed. Seems odd.

-- 
Darren New / San Diego, CA, USA (PST)


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 3 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.