![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 05 Sep 2008 19:46:19 +0200, Orchid XP v8 <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> 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. :-)
It's also not necessary to understand how something works just to use it
s public interface. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 05 Sep 2008 18:35:16 -0400, gregjohn wrote:
> 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.
Not sure why you wrote this back to me - I was just commenting that
ntfs-3g solves the issues with native NTFS solutions in the Linux kernel.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 05 Sep 2008 21:34:01 -0700, Darren New wrote:
> 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. :-)
I believe that's how it works - much like how ndiswrapper can be used to
use Windows WLAN drivers on Linux.
But using a closed-source driver doesn't mean you have any idea how it
works, just how to interface with it - and that's what reverse
engineering is for.
>> 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.
Yeah, I'd agree with that.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |