pc.mod -> part_msdos.mod (etc)

pc.mod -> part_msdos.mod (etc)

[Robert Millan]

Hi,

As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
I intend to prefix all partmap modules with "part_" and rename "pc" to
"part_msdos".

If anyone has an objection, please say it now.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: pc.mod -> part_msdos.mod (etc)

[Vladimir 'phcoder' Serbinenko]

On Tue, Aug 18, 2009 at 7:57 PM, Robert Millan<rmh@aybabtu.com> wrote:
>
> Hi,
>
> As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
> I intend to prefix all partmap modules with "part_" and rename "pc" to
> "part_msdos".
>
> If anyone has an objection, please say it now.
size paranoia: does it increase core size? By how much?
>
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: pc.mod -> part_msdos.mod (etc)

[Pavel Roskin]

On Tue, 2009-08-18 at 19:57 +0200, Robert Millan wrote:
> Hi,
> 
> As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
> I intend to prefix all partmap modules with "part_" and rename "pc" to
> "part_msdos".
> 
> If anyone has an objection, please say it now.

No objection.

-- 
Regards,
Pavel Roskin

Re: pc.mod -> part_msdos.mod (etc)

[Robert Millan]

On Tue, Aug 18, 2009 at 08:11:10PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Tue, Aug 18, 2009 at 7:57 PM, Robert Millan<rmh@aybabtu.com> wrote:
> >
> > Hi,
> >
> > As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
> > I intend to prefix all partmap modules with "part_" and rename "pc" to
> > "part_msdos".
> >
> > If anyone has an objection, please say it now.
> size paranoia: does it increase core size? By how much?

6 bytes.  I guess we can live with it?  :-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: pc.mod -> part_msdos.mod (etc)

[Robert Millan]

Done.

On Tue, Aug 18, 2009 at 07:57:51PM +0200, Robert Millan wrote:
> 
> Hi,
> 
> As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
> I intend to prefix all partmap modules with "part_" and rename "pc" to
> "part_msdos".
> 
> If anyone has an objection, please say it now.
> 
> -- 
> Robert Millan
> 
>   The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>   how) you may access your data; but nobody's threatening your freedom: we
>   still allow you to remove your data and not access it at all."
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
> 

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: pc.mod -> part_msdos.mod (etc)

[Vladimir 'phcoder' Serbinenko]

>> As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
>> I intend to prefix all partmap modules with "part_" and rename "pc" to
>> "part_msdos".
This partition scheme is "PC-style" ans calling it "msdos" effectively
means miscrediting IBM's work to Microsoft. I don't believe this to be
correct.

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: pc.mod -> part_msdos.mod (etc)

[Colin Watson]

On Sun, Aug 23, 2009 at 08:42:52PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> This partition scheme is "PC-style" ans calling it "msdos" effectively
> means miscrediting IBM's work to Microsoft. I don't believe this to be
> correct.

It's consistent with GNU Parted though ...

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: pc.mod -> part_msdos.mod (etc)

[Vladimir 'phcoder' Serbinenko]

It broke grub-install. I already fixed it.

On Sun, Aug 23, 2009 at 2:01 PM, Robert Millan<rmh@aybabtu.com> wrote:
>
> Done.
>
> On Tue, Aug 18, 2009 at 07:57:51PM +0200, Robert Millan wrote:
>>
>> Hi,
>>
>> As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
>> I intend to prefix all partmap modules with "part_" and rename "pc" to
>> "part_msdos".
>>
>> If anyone has an objection, please say it now.
>>
>> --
>> Robert Millan
>>
>>   The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>>   how) you may access your data; but nobody's threatening your freedom: we
>>   still allow you to remove your data and not access it at all."
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: pc.mod -> part_msdos.mod (etc)

[Vladimir 'phcoder' Serbinenko]

On Sun, Aug 23, 2009 at 8:42 PM, Vladimir 'phcoder'
Serbinenko<phcoder@gmail.com> wrote:
>>> As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
>>> I intend to prefix all partmap modules with "part_" and rename "pc" to
>>> "part_msdos".
> This partition scheme is "PC-style" ans calling it "msdos" effectively
> means miscrediting IBM's work to Microsoft. I don't believe this to be
> correct.
>
I've done a small research and wasn't able to find where does it come
exactly from but found that PC-DOS was a rebranded MS-DOS. As I don't
want to spend a lot of time researching the origin of this partition
scheme more in details I'm fine with any name.
> --
> Regards
> Vladimir 'phcoder' Serbinenko
>
> Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: pc.mod -> part_msdos.mod (etc)

[Robert Millan]

On Sun, Aug 23, 2009 at 08:42:52PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >> As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
> >> I intend to prefix all partmap modules with "part_" and rename "pc" to
> >> "part_msdos".
> This partition scheme is "PC-style" ans calling it "msdos" effectively
> means miscrediting IBM's work to Microsoft. I don't believe this to be
> correct.

Well, it's a bit more complicated.  First of all, PC-style isn't appropiate.
"PC" is generally assumed to be hardware and perhaps firmware, but not OS
(otherwise if it doesn't run some version of DOS it's not a PC).

DOS is the operating system that introduced this partition layout.  I don't
know which version, or whether it had this layout from the very beginning; its
design patterns suggest some primitive version only had a filesystem with MBR
and no partition label at all.

Nowadays, DOS-derived operating systems (e.g. Windows Vista) are only being
developed by Microsoft, and this has been true for a long while.  I don't think
it's far-fetched to consider MSDOS the canonical implementation.

Besides, I think IBM can live without the agravation of having this crappy
design being attributed to them.  It's clearly not their fault that 30 years
later we're still living by such poor standards.

<joke>
IOW, there's no problem with miss-attributing something bad to Microsoft, even
if they didn't do it.  If they did something good, we could still attribute it
to them, but this never happened anyway.
</joke>

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: pc.mod -> part_msdos.mod (etc)

[Robert Millan]

On Sun, Aug 23, 2009 at 11:05:47PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> It broke grub-install. I already fixed it.

Sorry, and thanks! :-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: pc.mod -> part_msdos.mod (etc)

[Vladimir 'phcoder' Serbinenko]

On Mon, Aug 24, 2009 at 12:59 AM, Robert Millan<rmh@aybabtu.com> wrote:
> On Sun, Aug 23, 2009 at 11:05:47PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> It broke grub-install. I already fixed it.
>
> Sorry, and thanks! :-)
>
Actually my first fix wasn't ok for efi and LVM users. New fix opens
new door: currently grub-probe transforms partition name into module
name. Why not actually make them coincide? E.g. rename
'msdos_partition_map' to 'part_msdos' ?
This would simplify the code
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: pc.mod -> part_msdos.mod (etc)

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

On Mon, Aug 24, 2009 at 1:43 AM, Vladimir 'phcoder'
Serbinenko<phcoder@gmail.com> wrote:
> On Mon, Aug 24, 2009 at 12:59 AM, Robert Millan<rmh@aybabtu.com> wrote:
>> On Sun, Aug 23, 2009 at 11:05:47PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>>> It broke grub-install. I already fixed it.
>>
>> Sorry, and thanks! :-)
>>
> Actually my first fix wasn't ok for efi and LVM users. New fix opens
> new door: currently grub-probe transforms partition name into module
> name. Why not actually make them coincide? E.g. rename
> 'msdos_partition_map' to 'part_msdos' ?
> This would simplify the code
Patch for it
>> --
>> Robert Millan
>>
>>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>>  how) you may access your data; but nobody's threatening your freedom: we
>>  still allow you to remove your data and not access it at all."
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
>
> --
> Regards
> Vladimir 'phcoder' Serbinenko
>
> Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

[-- Attachment #2: part.diff --]
[-- Type: text/plain, Size: 6340 bytes --]

diff --git a/ChangeLog b/ChangeLog
index 80d3f89..759b53d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,9 +1,18 @@
-2009-08-23  Vladimir Serbinenko  <phcoder@gmail.com>
-
-	Fix grub-install.
+2009-08-24  Vladimir Serbinenko  <phcoder@gmail.com>
 
-	* util/grub-probe.c (probe_partmap): Prefix partmap with 'part_'.
+	Rename *_partition_map to part_*
 
+	* partmap/acorn.c (grub_acorn_partition_map): Set name to 'part_acorn'.
+	* partmap/amiga.c (grub_amiga_partition_map): Set name to 'part_amiga'.
+	* partmap/apple.c (grub_apple_partition_map): Set name to 'part_apple'.
+	* partmap/gpt.c (grub_gpt_partition_map): Set name to 'part_gpt'.
+	All users updated.
+	* partmap/msdos.c (grub_msdos_partition_map): Set name to 'part_msdos'.
+	All users updated.
+	* partmap/sun.c (grub_sun_partition_map): Set name to 'part_sun'.
+	* util/grub-probe.c (probe_partmap): Don't transform partition name
+	to get module name.
+	
 2009-08-23  Vladimir Serbinenko  <phcoder@gmail.com>
 
 	* fs/hfsplus.c (grub_hfsplus_mount): Don't ignore grub_hfsplus_read_file
diff --git a/partmap/acorn.c b/partmap/acorn.c
index 42fd61f..e005975 100644
--- a/partmap/acorn.c
+++ b/partmap/acorn.c
@@ -189,7 +189,7 @@ acorn_partition_map_get_name (const grub_partition_t p)
 /* Partition map type.  */
 static struct grub_partition_map grub_acorn_partition_map =
 {
-  .name = "Linux/ADFS partition map",
+  .name = "part_acorn",
   .iterate = acorn_partition_map_iterate,
   .probe = acorn_partition_map_probe,
   .get_name = acorn_partition_map_get_name
diff --git a/partmap/amiga.c b/partmap/amiga.c
index ffb807f..dce9f4f 100644
--- a/partmap/amiga.c
+++ b/partmap/amiga.c
@@ -198,7 +198,7 @@ amiga_partition_map_get_name (const grub_partition_t p)
 /* Partition map type.  */
 static struct grub_partition_map grub_amiga_partition_map =
   {
-    .name = "amiga_partition_map",
+    .name = "part_amiga",
     .iterate = amiga_partition_map_iterate,
     .probe = amiga_partition_map_probe,
     .get_name = amiga_partition_map_get_name
diff --git a/partmap/apple.c b/partmap/apple.c
index 04ccff1..4dea55a 100644
--- a/partmap/apple.c
+++ b/partmap/apple.c
@@ -241,7 +241,7 @@ apple_partition_map_get_name (const grub_partition_t p)
 /* Partition map type.  */
 static struct grub_partition_map grub_apple_partition_map =
   {
-    .name = "apple_partition_map",
+    .name = "part_apple",
     .iterate = apple_partition_map_iterate,
     .probe = apple_partition_map_probe,
     .get_name = apple_partition_map_get_name
diff --git a/partmap/gpt.c b/partmap/gpt.c
index e860f35..4a49574 100644
--- a/partmap/gpt.c
+++ b/partmap/gpt.c
@@ -176,7 +176,7 @@ gpt_partition_map_get_name (const grub_partition_t p)
 /* Partition map type.  */
 static struct grub_partition_map grub_gpt_partition_map =
   {
-    .name = "gpt_partition_map",
+    .name = "part_gpt",
     .iterate = gpt_partition_map_iterate,
     .probe = gpt_partition_map_probe,
     .get_name = gpt_partition_map_get_name
diff --git a/partmap/msdos.c b/partmap/msdos.c
index 9fc620d..d0fc18e 100644
--- a/partmap/msdos.c
+++ b/partmap/msdos.c
@@ -303,7 +303,7 @@ pc_partition_map_get_name (const grub_partition_t p)
 /* Partition map type.  */
 static struct grub_partition_map grub_msdos_partition_map =
   {
-    .name = "msdos_partition_map",
+    .name = "part_msdos",
     .iterate = pc_partition_map_iterate,
     .probe = pc_partition_map_probe,
     .get_name = pc_partition_map_get_name
diff --git a/partmap/sun.c b/partmap/sun.c
index ce6d588..e816ec1 100644
--- a/partmap/sun.c
+++ b/partmap/sun.c
@@ -196,7 +196,7 @@ sun_partition_map_get_name (const grub_partition_t p)
 /* Partition map type.  */
 static struct grub_partition_map grub_sun_partition_map =
   {
-    .name = "sun_partition_map",
+    .name = "part_sun",
     .iterate = sun_partition_map_iterate,
     .probe = sun_partition_map_probe,
     .get_name = sun_partition_map_get_name
diff --git a/parttool/msdospart.c b/parttool/msdospart.c
index 1bb9cd3..dbb25bc 100644
--- a/parttool/msdospart.c
+++ b/parttool/msdospart.c
@@ -140,10 +140,10 @@ static grub_err_t grub_pcpart_type (const grub_device_t dev,
 
 GRUB_MOD_INIT (pcpart)
 {
-  activate_table_handle = grub_parttool_register ("msdos_partition_map",
+  activate_table_handle = grub_parttool_register ("part_msdos",
 						  grub_pcpart_boot,
 						  grub_pcpart_bootargs);
-  type_table_handle = grub_parttool_register ("msdos_partition_map",
+  type_table_handle = grub_parttool_register ("part_msdos",
 					      grub_pcpart_type,
 					      grub_pcpart_typeargs);
 
diff --git a/util/grub-probe.c b/util/grub-probe.c
index c8dbc01..affa1c8 100644
--- a/util/grub-probe.c
+++ b/util/grub-probe.c
@@ -80,7 +80,6 @@ static void
 probe_partmap (grub_disk_t disk)
 {
   char *name;
-  char *underscore;
 
   if (disk->partition == NULL)
     {
@@ -92,12 +91,7 @@ probe_partmap (grub_disk_t disk)
   if (! name)
     grub_util_error ("Not enough memory");
 
-  underscore = strchr (name, '_');
-  if (! underscore)
-    grub_util_error ("Invalid partition map %s", name);
-
-  *underscore = '\0';
-  printf ("part_%s\n", name);
+  printf ("%s\n", name);
   free (name);
 }
 
diff --git a/util/hostdisk.c b/util/hostdisk.c
index 8a3e2ef..a06ecca 100644
--- a/util/hostdisk.c
+++ b/util/hostdisk.c
@@ -949,7 +949,7 @@ grub_util_biosdisk_get_grub_dev (const char *os_dev)
       {
  	struct grub_msdos_partition *pcdata = NULL;
 
-	if (strcmp (partition->partmap->name, "msdos_partition_map") == 0)
+	if (strcmp (partition->partmap->name, "part_msdos") == 0)
 	  pcdata = partition->data;
 
 	if (pcdata)
diff --git a/util/i386/pc/grub-setup.c b/util/i386/pc/grub-setup.c
index 0dc2e2c..7f38c42 100644
--- a/util/i386/pc/grub-setup.c
+++ b/util/i386/pc/grub-setup.c
@@ -279,7 +279,7 @@ setup (const char *dir,
       if (root_dev->disk->partition)
 	{
 	  if (strcmp (root_dev->disk->partition->partmap->name,
-		      "msdos_partition_map") == 0)
+		      "part_msdos") == 0)
 	    {
 	      struct grub_msdos_partition *pcdata =
 		root_dev->disk->partition->data;
@@ -287,7 +287,7 @@ setup (const char *dir,
 	      bsd_part = pcdata->bsd_part;
 	    }
 	  else if (strcmp (root_dev->disk->partition->partmap->name,
-			   "gpt_partition_map") == 0)
+			   "part_gpt") == 0)
 	    {
 	      dos_part = root_dev->disk->partition->index;
 	      bsd_part = -1;

Re: pc.mod -> part_msdos.mod (etc)

[Robert Millan]

On Mon, Aug 24, 2009 at 02:07:45AM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Mon, Aug 24, 2009 at 1:43 AM, Vladimir 'phcoder'
> Serbinenko<phcoder@gmail.com> wrote:
> > On Mon, Aug 24, 2009 at 12:59 AM, Robert Millan<rmh@aybabtu.com> wrote:
> >> On Sun, Aug 23, 2009 at 11:05:47PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >>> It broke grub-install. I already fixed it.
> >>
> >> Sorry, and thanks! :-)
> >>
> > Actually my first fix wasn't ok for efi and LVM users. New fix opens
> > new door: currently grub-probe transforms partition name into module
> > name. Why not actually make them coincide? E.g. rename
> > 'msdos_partition_map' to 'part_msdos' ?
> > This would simplify the code
> Patch for it

Yeah, and make it a bit smaller.  Seems fine.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: pc.mod -> part_msdos.mod (etc)

[Yves Blusseau]

> As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
> I intend to prefix all partmap modules with "part_" and rename "pc" to
> "part_msdos".
>
> If anyone has an objection, please say it now.

Is it normal that i see gpt when i do a lsmod instead of part_gpt ?

Regards,
Yves Blusseau

Re: pc.mod -> part_msdos.mod (etc)

[Yves Blusseau]

>> As was discussed in http://www.mail-archive.com/grub-devel@gnu.org/msg06210.html
>> I intend to prefix all partmap modules with "part_" and rename "pc"  
>> to
>> "part_msdos".
>>
>> If anyone has an objection, please say it now.
>
> Is it normal that i see gpt when i do a lsmod instead of part_gpt ?

Sorry i made a mistake. lsmod return part_gpt not gpt.

Yves

Module autoloading?

[Seth Goldberg]

Hi,

   Has the idea come up of having a file that maps commands to module names 
along with the required code to autoload the corresponding module(s) when the 
corresponding commands are used (something like:

<commandname>:	<modulename>.mod [, <modulename>.mod ...]

i.e.:

multiboot:	multiboot.mod
linux:		linux.mod
...
\


(Obviously, we could also have the convention of trying to load 
<commandname>.mod, but having an explicit mapping would remove the overhead of 
trying to find a module that doesn't exist, and loading multiple modules may 
not be needed as well).

  --S

Re: Module autoloading?

[Vladimir 'phcoder' Serbinenko]

On Wed, Sep 2, 2009 at 7:04 AM, Seth Goldberg<Seth.Goldberg@sun.com> wrote:
> Hi,
>
>  Has the idea come up of having a file that maps commands to module names
> along with the required code to autoload the corresponding module(s) when
> the corresponding commands are used (something like:
Actually it's already implemented. Look a commands.lst and normal/dyncmd.c
>
> <commandname>:  <modulename>.mod [, <modulename>.mod ...]
>
> i.e.:
>
> multiboot:      multiboot.mod
> linux:          linux.mod
> ...
> \
>
>
> (Obviously, we could also have the convention of trying to load
> <commandname>.mod, but having an explicit mapping would remove the overhead
> of trying to find a module that doesn't exist, and loading multiple modules
> may not be needed as well).
>
>  --S
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Module autoloading?

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1505 bytes --]



  Duh. Sorry about that.  I was getting "unknown command" errors.  I'll try to be a 
bit more investigative in the future.

  --S


Quoting Vladimir 'phcoder' Serbinenko, who wrote the following on Wed, 2...:

> On Wed, Sep 2, 2009 at 7:04 AM, Seth Goldberg<Seth.Goldberg@sun.com> wrote:
>> Hi,
>>
>>  Has the idea come up of having a file that maps commands to module names
>> along with the required code to autoload the corresponding module(s) when
>> the corresponding commands are used (something like:
> Actually it's already implemented. Look a commands.lst and normal/dyncmd.c
>>
>> <commandname>:  <modulename>.mod [, <modulename>.mod ...]
>>
>> i.e.:
>>
>> multiboot:      multiboot.mod
>> linux:          linux.mod
>> ...
>> \
>>
>>
>> (Obviously, we could also have the convention of trying to load
>> <commandname>.mod, but having an explicit mapping would remove the overhead
>> of trying to find a module that doesn't exist, and loading multiple modules
>> may not be needed as well).
>>
>>  --S
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
>
> -- 
> Regards
> Vladimir 'phcoder' Serbinenko
>
> Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Enable pager by default for the help command

[Seth Goldberg]

Hi,

   I know I've been annoyed by this (as have many others I've talked to).  How 
about we enabling paging (set pager=1) automatically for the duration of the 
help command, since it will inevitable scroll off of the screen for 
console output devices with a limited number of lines?

  --S

Re: Enable pager by default for the help command

[Robert Millan]

On Wed, Sep 02, 2009 at 04:45:28PM -0700, Seth Goldberg wrote:
> Hi,
>
>   I know I've been annoyed by this (as have many others I've talked to).  
> How about we enabling paging (set pager=1) automatically for the duration 
> of the help command, since it will inevitable scroll off of the screen 
> for console output devices with a limited number of lines?

We can't do this, as it could make GRUB unexpectedly require manual
assistance to boot in certain setups.

If this problem is solved, I suppose it's fine, but it would have to be
post-1.97.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Enable pager by default for the help command

[Seth Goldberg]

Quoting Robert Millan, who wrote the following on Thu, 3 Sep 2009:

> On Wed, Sep 02, 2009 at 04:45:28PM -0700, Seth Goldberg wrote:
>> Hi,
>>
>>   I know I've been annoyed by this (as have many others I've talked to).
>> How about we enabling paging (set pager=1) automatically for the duration
>> of the help command, since it will inevitable scroll off of the screen
>> for console output devices with a limited number of lines?
>
> We can't do this, as it could make GRUB unexpectedly require manual
> assistance to boot in certain setups.

   Really?  When is the help command executed as part of boot?  I'm not asking 
for pager to be set to 1 by default-- ONLY during the execution of the help 
command.

>
> If this problem is solved, I suppose it's fine, but it would have to be
> post-1.97.

   This is a big dissatisfier with pretty much everyone I've talked to who's 
needed help.  I suppose as long as it's well-documented in the manual, that 
would be a minor improvement.

  --S

Re: Enable pager by default for the help command

[Robert Millan]

On Thu, Sep 03, 2009 at 09:30:31AM -0700, Seth Goldberg wrote:
>
>
> Quoting Robert Millan, who wrote the following on Thu, 3 Sep 2009:
>
>> On Wed, Sep 02, 2009 at 04:45:28PM -0700, Seth Goldberg wrote:
>>> Hi,
>>>
>>>   I know I've been annoyed by this (as have many others I've talked to).
>>> How about we enabling paging (set pager=1) automatically for the duration
>>> of the help command, since it will inevitable scroll off of the screen
>>> for console output devices with a limited number of lines?
>>
>> We can't do this, as it could make GRUB unexpectedly require manual
>> assistance to boot in certain setups.
>
>   Really?  When is the help command executed as part of boot?  I'm not 
> asking for pager to be set to 1 by default-- ONLY during the execution of 
> the help command.

Ah, sorry I overlooked this part.  Well, it wouldn't harm in help command,
but I suppose other commands are in the same situation.  Hopefully we could
find a more generic solution instead?

>   This is a big dissatisfier with pretty much everyone I've talked to 
> who's needed help.

Believe me, I'm annoyed by this problem too.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Enable pager by default for the help command

[Seth Goldberg]

Quoting Robert Millan, who wrote the following on Thu, 3 Sep 2009:

> On Thu, Sep 03, 2009 at 09:30:31AM -0700, Seth Goldberg wrote:
>>
>>
>> Quoting Robert Millan, who wrote the following on Thu, 3 Sep 2009:
>>
>>> On Wed, Sep 02, 2009 at 04:45:28PM -0700, Seth Goldberg wrote:
>>>> Hi,
>>>>
>>>>   I know I've been annoyed by this (as have many others I've talked to).
>>>> How about we enabling paging (set pager=1) automatically for the duration
>>>> of the help command, since it will inevitable scroll off of the screen
>>>> for console output devices with a limited number of lines?
>>>
>>> We can't do this, as it could make GRUB unexpectedly require manual
>>> assistance to boot in certain setups.
>>
>>   Really?  When is the help command executed as part of boot?  I'm not
>> asking for pager to be set to 1 by default-- ONLY during the execution of
>> the help command.
>
> Ah, sorry I overlooked this part.  Well, it wouldn't harm in help command,
> but I suppose other commands are in the same situation.  Hopefully we could
> find a more generic solution instead?

   I was just looking for low-hanging fruit :).  I think we should examine 
other cases as they arise.

>
>>   This is a big dissatisfier with pretty much everyone I've talked to
>> who's needed help.
>
> Believe me, I'm annoyed by this problem too.

   Is that an approval I hear to get it in to 1.97? ;) .

  --S

Re: Enable pager by default for the help command

[Robert Millan]

On Thu, Sep 03, 2009 at 11:00:51AM -0700, Seth Goldberg wrote:
>>>   This is a big dissatisfier with pretty much everyone I've talked to
>>> who's needed help.
>>
>> Believe me, I'm annoyed by this problem too.
>
>   Is that an approval I hear to get it in to 1.97? ;) .

Sorry, this seems like 1.98 material.  But I'd like to find a good solution,
otherwise this would have been "solved" already.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."