[haiku-development] Re: CD boot - KPath::Lock()
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 06 Feb 2009 17:20:31 +0100
Hi,
> I spent sometime trying to fix an imaginary bug (the session addons
> seems to actually work fine, QEMU was just faking a single track)...
> Now CD boot breaks after mounting /boot, in scan_for_drivers() ->
> legacy_driver_probe() -> find_directory(0x3ea, 3, true, NULL, 0x400) ->
> strlcpy(NULL, , 0x400).
>
> It seems find_directory() is iterated on the USER/COMMON/BEOS addon
> dirs, with true (create it) passed, and KPath::Lock() as target buffer.
>
> As the common/add-ons folder probably doesn't exist in the image,
> find_directory() fails to create it, returning with an error, leaving
> the KPath locked.
>
> At next iter, find_directory() is called again, but KPath::Lock()
> returns NULL as it's already locked.
>
> What's the rationale behind returning NULL on already locked ? is it
> wanted behaviour ?
It's probably intented. But the whole find_directory() in the kernel thing was
something that I wanted to revert. It doesn't give any benefit over hardcoded
paths. Whenever we will change something with the filesystem layout, the kernel
is going to be adopted first anyways.
Best regards,
-Stephan
Other related posts:
