search for: allowedit

...> > At this point the 8 or 9 com32 modules I listed earlier stopped working > when ALLOWOPTIONS was set. This is a change from the previous 6 years > of behavior. > > But, if we still have different views on this, it looks like ALLOWOPTIONS > is internally referred to as 'allowedit' in the menu code. Perhaps > we can separate them there, maintaining an ALLOWOPTIONS' variable for > load_kernel to check, but also adding a ALLOWEDIT option that the menu > can use to restrict the Tab to edit functionality. > > Thoughts? > I do agree that the current b...

> I didn't see any further communication here; would anyone be > against my submitting/proposing a patch for this? Contributions are always welcome. > > I can see two possible approaches. One approach would be to > isolate the restriction on user commands away from > syslinux_run_command / load_kernel. > > Another would perhaps be to add support for a

...c55ed4f39d6c625b017bb16907f7d50c05 At this point the 8 or 9 com32 modules I listed earlier stopped working when ALLOWOPTIONS was set. This is a change from the previous 6 years of behavior. But, if we still have different views on this, it looks like ALLOWOPTIONS is internally referred to as 'allowedit' in the menu code. Perhaps we can separate them there, maintaining an ALLOWOPTIONS' variable for load_kernel to check, but also adding a ALLOWEDIT option that the menu can use to restrict the Tab to edit functionality. Thoughts? --------- That text came from a message that I undercep...

...the 8 or 9 com32 modules I listed earlier stopped working > > when ALLOWOPTIONS was set. This is a change from the previous 6 years > > of behavior. > > > > But, if we still have different views on this, it looks like ALLOWOPTIONS > > is internally referred to as 'allowedit' in the menu code. Perhaps > > we can separate them there, maintaining an ALLOWOPTIONS' variable for > > load_kernel to check, but also adding a ALLOWEDIT option that the menu > > can use to restrict the Tab to edit functionality. > > > > Thoughts? > >...

It appears that the 3.74 completely broke the "keeppxe" directive -- not due to the command-line parser, but due to mishandling of the flag later. I consider this to be severe enough to do a short-cycle 3.75. As a result, I would like help with: a) are there any other bugs that snuck through? b) once I have a 3.75-pre1, I would really appreciate help testing it. The goal is to have

...kipspace(p + 13)) * CLK_TCK + 9) / 10; } else if (looking_at(p, "ontimeout")) { - m->ontimeout = refstrdup(skipspace(p + 9)); + ontimeout = refstrdup(skipspace(p + 9)); + ontimeoutlen = strlen(ontimeout); } else if (looking_at(p, "allowoptions")) { - m->allowedit = !!atoi(skipspace(p + 12)); + allowoptions = !!atoi(skipspace(p + 12)); } else if (looking_at(p, "ipappend")) { if (ld.label) ld.ipappend = atoi(skipspace(p + 8)); diff --git a/com32/include/menu.h b/com32/include/menu.h index 1db4d7c..ba6b9ce 100644 --- a/com32/include/me...

From: Matt Fleming <matt.fleming at linux.intel.com> This series fixes some bugs and switches the elflink branch to be entirely ELF modules. It applies on top of, http://syslinux.zytor.com/archives/2011-April/016369.html The deletions in the diff stat below are mainly from deleting com32/elflink/modules (finally!). Now there should be no duplicate code because we don't need COM32 and

From: Matt Fleming <matt.fleming at linux.intel.com> This is a series of patches that, * shrink the core by moving things into an ldlinux ELF module * begin wiring up some of the C versions of various functions The core now only contains essential code and loads the ldlinux module to do everything else, like providing a command line interface and loading kernels. The config file parsing