H. Peter Anvin
2007-Jun-07 02:55 UTC
[syslinux] SYSLINUX current directory and the config file
Hi all, I have looked a bit at what it would take to make the SYSLINUX current directory settable when loading a new configuration file with the CONFIG directive. I have come to the conclusion that it would be a lot less invasive to simply maintain the rule that the current working directory is the one where the config file lives, *including* one loaded via the CONFIG directive. The obvious exception to this would be the initially loaded PXELINUX configuration file. If there are ideas how better to handle the PXELINUX case I would appreciate hearing them. Would this be sufficient for people, or would everyone prefer the full-blown solution? That would probably have to wait until post-3.50 just due to the invasiveness of some of the changes. -hpa
H. Peter Anvin
2007-Jun-07 03:07 UTC
[syslinux] SYSLINUX current directory and the config file
H. Peter Anvin wrote:> > Would this be sufficient for people, or would everyone prefer the > full-blown solution? That would probably have to wait until post-3.50 > just due to the invasiveness of some of the changes. >I should probably point out that if the current 3.50 behavior goes out (CONFIG doesn't change the current directory) I don't want to break people's config files later. -hpa
Ferenc Wagner
2007-Jun-07 14:29 UTC
[syslinux] SYSLINUX current directory and the config file
"H. Peter Anvin" <hpa at zytor.com> writes:> I have come to the conclusion that it would be a lot less invasive to > simply maintain the rule that the current working directory is the one > where the config file lives, *including* one loaded via the CONFIG > directive.Yes, that would suffice for me.> The obvious exception to this would be the initially loaded PXELINUX > configuration file. If there are ideas how better to handle the > PXELINUX case I would appreciate hearing them.The parent directory (containing pxelinux.cfg) seems like a logical choice for me.> Would this be sufficient for people, or would everyone prefer the > full-blown solution? That would probably have to wait until > post-3.50 just due to the invasiveness of some of the changes.Btw, I tried testing those patches under Bochs, but that froze right after printing CBIOS, much sooner than QEMU. I admit I cheated during compilation by touching {pxe,ext,iso}linux.bin as those won't compile without proper conditional compilation directives; hope that didn't matter. The result is an infinite number of 00003899960i[CPU0 ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0) type messages pouring onto the console. Unless you declare it worthless I'll continue looking into this as time permits. -- Regards, Feri.