Mount ext2 FS in MacOS X

fddi1

Registered
Is there a way to mount a Linux ext2 file system in MacOS X (Jaguar to be exact). Thanks in advance.
 
So far I haven't found any way to mount ext2 filesystems. The Darwin Kernel doesn't support them natively, but since it's a microkernel, it should be easy enough to load in a module to handle other filesystems. Unfortunately, I don't think anyone has written any such modules yet. Drat!
 
The Darwin kernel, xnu, is not a microkernel. Furthermore whether it is or isn't a microkernel has absolutely nothing to do with what filesystems it supports or how easy it would be to support a new filesystem.

I don't know the setup of the person who started this thread, but I would suggest transferring files over a network. If the person is running a dual-boot setup of some sort then I would suggest keeping common files in a filesystem which both OSs can use. IIRC there is an HFS+ module for Linux but don't hold me to that. Both also support Fat32 IIRC. And there is of course UFS (although I'm not sure if UFS is universal).
 
Well, whatever the hell it is, it supports dynamically loadable kernel modules. Usually it's easier for the end user to just load a module than to rebuild the whole kernel from source. And I didn't say the implementation would be any easier - but loading the module to enable support sure would be.
 
I don't see what that has to do with microkernels.

In Mac OS X you shouldn't ever have to load a kernel module. Kernel modules are bundled into KEXTs or kernel extensions which contain information which tell the KEXT daemon when it should be loaded. Thus if you implement the KEXT correctly it will be loaded when a partition of that filesystem is detected.

It doesn't sound like you know what you're talking about, as if you're treating Mac OS X like BSD or Linux.
 
It doesn't sound like you read what I'm talking about. Modules: easy to load, and quick availability of functionality. That's all. If you're going to support a filesystem, this is great, since you can just load and unload the module as necessary without needing to rebuild the whole kernel.

So a good KEXT will automate the process, and make this even easier. Cool. But how is that contradictory to something I said?

And as for what it has to do with microkernels, I'd say kind of a lot, since they depend on external modules for most of their functionality.
 
It is contradictory because you suggested that a) a microkernel would be necessary or more apt, b) a module would have to be loaded in order to 'handle' the filesystem. In fact you kind of implied that Darwin supports some filesystems natively which I don't believe to be correct.

Furthermore I don't think any of this helps the person who posted the question. I'm only addressing the misinformation.

Darwin depends on modules for most of its functionality, but this doesn't make it a microkernel. The same could be said for Linux.

A microkernel is typically defined as a small binary which provides bare essential services (threads, pager, etc.) via messages and can execute 'servers' on a separate thread, like the BSD kernel or the MkLinux kernel or NeXTSTEP on top of the OSF Mach kernel. It doesn't have anything to do with modules. In fact in these three examples the modules may use Mach threads or other services but they aren't loaded by or linked to Mach. They are loaded by the respective Mach server like BSD.

Modules thus have nothing to do with microkernels.
 
I think you're reading way too much into what I'm saying. My original implication was that since Darwin's kernel supports dynamic modules, it would be easy for an end user to add ext2 filesystem functionality, if a module supporting that existed. And like I said, I haven't seen such a module yet. Since the folks that made Sharity didn't seem to have any trouble writing a module to support CIFS mounts, I would presume that making a KEXT to support a filesystem isn't any more difficult than it needs to be. That's all. No more - no less.
 
What happened to me was my RH Linux box recently just died. So I need to move my data from it to somewhere else. Since the RH Linux was using ext2 FS, I was hoping to get a firewire enclose and put the hard drive in, then mounted the FS under OS X. So NFS or any other network transfer mechanisms are out of the question here.
 
Hmm, I guess your best bet would be to stuff the drive into the cheapest Linux system you can get your hands on, and just dump the data across the network. It's not a very pleasant solution, I know.
 
Originally posted by strobe
You don't need to buy a whole new system silly, just boot off a Linux/PPC CD. Yeesh.

Well, he said he had a Red Hat system, and last time I checked, Red Hat doesn't boot too well on PPCs, let alone Macs. Enough of the hostile posts already; it's not helping any.

If you've got a PPC Linux CD that you can boot in such a way that you've got read/write access to one of your data partitions, then go for it. Better yet, maybe you could stuff the ext2 drive in the Mac and install a fresh copy of Yellow Dog Linux on it, then boot from that and move your data. Of course, this is assuming that you have access to Yellow Dog CDs, are willing to overwrite the old Red Hat installation, and you've got the patience necessary to actually get yaboot installed and booting Yellow Dog properly. It's certainly not easier than puting the drive into a different x86 system, but it would be cheaper.
 
Heh... I just had this idea, but not sure if it would work. If I installed Virtual PC and put RH Linux on it, would it recognize the mount?;)
 
Hmm, you know that has potential... This is a bit of rambling, but it might work.

Install Virtual PC. Put Linux on a small disk image. Install the ext2 disk in your Mac. DON'T format it if the Finder asks. Use Disk Copy to "Make Image from Device," or whatever it's called, and store the entire disk as whatever image type is compatible with Virtual PC. It'll probably just be a read/write uncompressed image. You're going to need a lot of spare disk space to do that, but it would sure be worth a shot. Hopefully your ext2 partition isn't too high in double digit gigabytes.

I don't know if Virtual PC can mount a device directly, but if it can, then you can skip the disk image step and just try using the disk.

If anyone can comment on why this wouldn't work, now's your chance. :)
 
Originally posted by strobe
The Darwin kernel, xnu, is not a microkernel. Furthermore whether it is or isn't a microkernel has absolutely nothing to do with what filesystems it supports or how easy it would be to support a new filesystem.

MacOSX uses the Mach 3.0 kernel. this is a microkernel. in fact, this is _the_ microkernel. windows NT-2000-XP also uses a microkernel. the GNU system (AKA GNU/HURD) also uses a microkernel, the mach 3 microkernel, the same as Mac OS X.

the darwin implementation of Mach 3.0 is known as xnu.

by the way, strobe, having no native filesystems, and having dynamically loadable modules, while no definitive, does go a long way towards making a kernel a microkernel. every monolithic kernel has FS support hardwired in.

furthermore, whether or not it is a microkernel has _everything_ to do with how easy it is to add filesystem support. in fact, this was the whole principle behind the microkernel design. to make the kernel modular and extensible. it is much much easier and safer to add a filesystem module to a microkernel than to hardwire a new filesystem into a monolithic kernel. due to the obvious superiority of this architecture, even most monolithic kernels today have some support for dynamically loadable drivers, and therefore share some features with microkernels.

Originally posted by strobe
I don't see what that has to do with microkernels.

Umm... that is practically the definition of a microkernel.

Originally posted by strobe
Modules thus have nothing to do with microkernels.

Microkernel (from nightflight): An approach to operating system design emphasising small modules that implement the basic features of the system kernel and can be flexibly configured.

strobe: modules have quite a lot to do with microkernels. in fact they are the defining characteristic of a microkernel.

strobe, i am having my doubts as to whether you know what you re talking about, apropos kernel design. you should not be quite so aggressive in your posts, claiming someone does not know what he is talkign about unless you are truly an expert, you know?

now as to whether the fact that OSX has a microkernel will help some end user, it is not likely. but remember, the easier it is for developers to add features, the more likely it is to happen, and that benefits our end user. and ease of extensibilty is the major force in the microkernel design.
 
Originally posted by fddi1
Heh... I just had this idea, but not sure if it would work. If I installed Virtual PC and put RH Linux on it, would it recognize the mount?;)

No
 
Originally posted by lethe
MacOSX uses the Mach 3.0 kernel. this is a microkernel. in fact, this is _the_ microkernel. windows NT-2000-XP also uses a microkernel. the GNU system (AKA GNU/HURD) also uses a microkernel, the mach 3 microkernel, the same as Mac OS X.

the darwin implementation of Mach 3.0 is known as xnu.


Wrong.

xnu is not Mach. xnu is based on a lot of technologies and borrows a lot from OSF Mach 3 including some technologies which aren't in Mach 3 like realtime threads.

Just to say it again for effect, xnu is not Mach.


by the way, strobe, having no native filesystems, and having dynamically loadable modules, while no definitive, does go a long way towards making a kernel a microkernel. every monolithic kernel has FS support hardwired in.



Not true. You can remove all filesystem support from Linux if you wish. The problem there is Linux would need to be able to load modules by another mechanism which isn't available on PCs. This mechanism is however available on Open Firmware so you could do this with Linux/PPC. However nobody would want to waste their time doing it.

However it could be done and Linux would still be called a macrokernel.



furthermore, whether or not it is a microkernel has _everything_ to do with how easy it is to add filesystem support. in fact, this was the whole principle behind the microkernel design. to make the kernel modular and extensible. it is much much easier and safer to add a filesystem module to a microkernel than to hardwire a new filesystem into a monolithic kernel. due to the obvious superiority of this architecture, even most monolithic kernels today have some support for dynamically loadable drivers, and therefore share some features with microkernels.



Umm... that is practically the definition of a microkernel.



Microkernel (from nightflight): An approach to operating system design emphasising small modules that implement the basic features of the system kernel and can be flexibly configured.

strobe: modules have quite a lot to do with microkernels. in fact they are the defining characteristic of a microkernel.

strobe, i am having my doubts as to whether you know what you re talking about, apropos kernel design. you should not be quite so aggressive in your posts, claiming someone does not know what he is talkign about unless you are truly an expert, you know?

now as to whether the fact that OSX has a microkernel will help some end user, it is not likely. but remember, the easier it is for developers to add features, the more likely it is to happen, and that benefits our end user. and ease of extensibilty is the major force in the microkernel design.


The fundamental design of a microkernel is running 'servers' on separate threads which communicate to the kernel via messages. If you were correct in saying the defining characteristic of a microkernel is being modular then Linux would be a microkernel. Linux is not a microkernel.

You make it sound like Mac OS X modules are actually Mach modules (if there was such a thing). Apple even disuades people from using Mach threads and other Mach services directly in either application or driver development.

xnu is not a microkernel. xnu does not run servers, instead it is one giant binary. The BSD kernel does not run as a separate Mach server like it does in FreeBSD, NeXTSTEP, OPENSTEP, NetBSD, OpenBSD, MkLinux, or any other OS using the OSF Mach 3 kernel. Neither do the kernel modules run as Mach servers or processes.
 
By the way GNU HURD doesn't use "the" Mach 3 microkernel, it uses its own version of the Mach 3 microkernel, not the OSF Mach 3 microkernel.
 
Back
Top