Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Subject: using mount

> "John J. Francini" <email@hidden> wrote:
>
>> On Friday, March 29, 2002, at 09:15 PM, John J. Francini wrote:
>>
>>> In the "dumb question" department...
>>>
>>> If MacOS X/Darwin is supposed to be "real" unix, then would it make
>>> sense to teach mount/umount to do things the way that disktool -m
>>> /disktool -u does, so that Unix admin types (like me) can use a
>>> consistent utility across most platforms? If I'm administrating a
>>> bunch of Unixes, of which MacOS X happens to be just one of several
>>> flavors, having to know that "oh, yeah, can't use mount/umount on
>>> it 'cuz it doesn't talk right to upper level apps" makes it stand
>>> out as an exception.
>>>
>>> Would it be hard to add the disktool functionality to mount?
>>
>> It would not be hard, but probably not intelligent to add full disk
>> arbitration logic to mount and umount.
>>
>> Eric
>
> Okay, then what about making mount/umount actually go off and do a
> fork/exec of disktool "behind the scenes", as it were? What I don't
> seem to understand is the reticence in making mount/umount the
> standard command, even if it ends up having to call other tools to do
> its work.
>
> There's precedent for making the mount/umount commands "front-ends"
> for other programs that do the work on a filesystem-type by
> filesystem-type basis in some OSes. Tru64 UNIX, for example, has a
> single command interface for dealing with disks -- mount/umount.
> Depending on what it's mounting, it calls various subprograms to do
> the actual dirty work:
>
> o UFS: handles internally
> o AdvFS (log-based filesystem): mount_advfs
> o CDFS: mount_cdfs
> o MFS (ram disk): mount_mfs
> o NFS: mount_nfs
>
> None of these programs can be run interactively; they're all run
> indirectly after mount/umount has parsed the command line.
>
> Net result: easier administration since the command interface is very
> similar to all the other UNIXes.

Isn't this typically staged through inetd. Meaning rpc and socket
interfaces. As opposed to IOKit. What's the big difference?
I haven't a clue. On the local host sockets connect and communicate through
shared memory. Threads communicate through shared memory... Can anyone
explain what advantages there are in a non-standard implementation which
essentially is completely dependent upon having a Mach kernel? Would that
still be defined as an "OPEN SYSTEM"?


_p.
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.