[openbeosstorage] Re: session module
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 19 Feb 2003 21:53:27 +0100 CET
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > Oh yeah, I like that, too! :-)
> > Perhaps we can even have registrar (=3D3F) add-ons that take over the
> > job
> > of cddblinkd :-)
> > But of course, we could just let it run as a separate server as
> > well
> > (now without polling, since the new API allows for notifications :-
> > )
> It's probably not a bad idea to introduce a dedicated server that
> allows to add user add-ons with code that would otherwise be run in
> separate daemon. It should not be the registrar, I think, since it is
> `mission-critical', and one should better not need to risk the
> usability of the system when trying a third-party add-on.
Indeed, that's very true. Something like inetd for generic services :)
> > We could ask Marco if he would release the source to his cdda-fs.
> If he is allowed to do so...
Sure, that would be an important premise.
> > That sounds very reasonable! Then it's a matter of priorities which
> > partition module gets there, first.
> > Although in the case of iso9660 vs. HFS, normally HFS should be
> > preferred, because it allows for more information to be stored
> > (like
> > file types, long file names etc.).
> Nooo! I have the vague feeling you're trying to tease me. ;-)
> This has nothing to do with priorities and couldn't be solved by
> using
> them. I'll try to explain again:
>
> The session in question is partitioned Apple style and when looking
> at
> the partition(s) defined by it, we find a HFS formatted one. At the
> same time, when considering a virtual partition spanning the whole
> session (i.e. as if the session wasn't partitioned according to any
> scheme) we discover an ISO9660 volume on it. This works, since, as
> Tyler explained, the ISO9660 FS ignores the first 16 logical blocks,
> and that is where the Apple partitions are described.
I was not trying to tease you, really, I was just dumb :-))
> So, in fact only one partition module is in the game in the first
> place
> (unless you count the `virtual' partitioning, which is merely a
> fallback). Hence priorities for partition module won't have any
> effect
> in this situation. And in the current implementation partition module
> priorities are not included; for FSs they are, though.
Yes, and that should be in fact enough.
Adios...
Axel.
Other related posts:
