On Tue, 28 Oct 2003, Sam Vaughan wrote:
We're skipping the getattrlist call currently simply because we're
getting away with it. Looking at the other file systems'
implementations it looks like too much work for too little reward at
the moment.
If you end up doing volfs support, you'll need to support this. You'll also need this if you want to support CNID's, finder info, etc. But that might be irrelevent to what you're doing...
Your dummy /dev entry and single IOMedia object idea looks interesting
though. What is the connection that DiskArb uses to associate one of
your mounted disks with the dummy /dev entry and the published IOMedia
object? I trawled through the DiskArb code the other day and couldn't
see why it would particularly care that we don't have any IOMedia
objects.
The IOMedia object is there to just give it an icon and its the widget that publishes the /dev entry. Otherwise it does nothing. We use that DiskArb call that was mentioned earlier to have our daemon tell DiskArb to make our disk show up. Panther's DiskArb API has changed a good deal in Panther, so some/all of this might be invalid for that. If I recall correctly, DiskArb asks the IOKit for new IOMedia notifications so it can do its automatic disk mounting, so you could create a .filesystem bundle to handle mounting your widget though DiskArb using a .util (tool) program. --- Marek Kozubal marek@portents.com _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.