[PATCH 2.6.27-rc5 1/29] mdb: export ioapic read routines and detected ioapic count

[PATCH 2.6.27-rc5 1/29] mdb: export ioapic read routines and detected ioapic count

[jmerkey]

export ioapic read routines and detected ioapic count.


Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com)

--- a/arch/x86/kernel/io_apic_32.c	2008-08-28 14:19:19.000000000 -0600
+++ b/arch/x86/kernel/io_apic_32.c	2008-08-28 16:07:46.000000000 -0600
@@ -75,6 +75,7 @@
 /* I/O APIC entries */
 struct mp_config_ioapic mp_ioapics[MAX_IO_APICS];
 int nr_ioapics;
+EXPORT_SYMBOL(nr_ioapics);
 
 /* MP IRQ source entries */
 struct mp_config_intsrc mp_irqs[MAX_IRQ_SOURCES];
@@ -120,12 +121,13 @@
 		+ (mp_ioapics[idx].mp_apicaddr & ~PAGE_MASK);
 }
 
-static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
+unsigned int io_apic_read(unsigned int apic, unsigned int reg)
 {
 	struct io_apic __iomem *io_apic = io_apic_base(apic);
 	writel(reg, &io_apic->index);
 	return readl(&io_apic->data);
 }
+EXPORT_SYMBOL(io_apic_read);
 
 static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned int value)
 {

Re: [PATCH 2.6.27-rc5 1/29] mdb: export ioapic read routines and detected ioapic count

[Benny Halevy]

Jeff, general comment: can you please send your patches as replies
to a leading message so they all be linked as a single thread?
Threading them together is helpful for maintaining several
versions of your patchset and it's simpler to ignore if one's
not really interested in this topic at all.

Benny

On Aug. 29, 2008, 8:47 +0300, jmerkey@wolfmountaingroup.com wrote:
> export ioapic read routines and detected ioapic count.
> 
> 
> Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com)
> 
> --- a/arch/x86/kernel/io_apic_32.c	2008-08-28 14:19:19.000000000 -0600
> +++ b/arch/x86/kernel/io_apic_32.c	2008-08-28 16:07:46.000000000 -0600
> @@ -75,6 +75,7 @@
>  /* I/O APIC entries */
>  struct mp_config_ioapic mp_ioapics[MAX_IO_APICS];
>  int nr_ioapics;
> +EXPORT_SYMBOL(nr_ioapics);
>  
>  /* MP IRQ source entries */
>  struct mp_config_intsrc mp_irqs[MAX_IRQ_SOURCES];
> @@ -120,12 +121,13 @@
>  		+ (mp_ioapics[idx].mp_apicaddr & ~PAGE_MASK);
>  }
>  
> -static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
> +unsigned int io_apic_read(unsigned int apic, unsigned int reg)
>  {
>  	struct io_apic __iomem *io_apic = io_apic_base(apic);
>  	writel(reg, &io_apic->index);
>  	return readl(&io_apic->data);
>  }
> +EXPORT_SYMBOL(io_apic_read);
>  
>  static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned int value)
>  {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.27-rc5 1/29] mdb: export ioapic read routines and detected ioapic count

[jmerkey]

> Jeff, general comment: can you please send your patches as replies
> to a leading message so they all be linked as a single thread?
> Threading them together is helpful for maintaining several
> versions of your patchset and it's simpler to ignore if one's
> not really interested in this topic at all.
>
> Benny
>

Hi Benny,

I was already scolded about this by a few folks.  I had not located the
git email programs when I submitted this project and I wrote something
myself to submit them.  (see attached).  I have thrown the program in the
trash I wrote to do this and moved to git.

Now I have reviewed the git clients and patch tools and I understand and
will use git and I see now why git works this way with the reply chain. I
will not be submitting patch series on this list for every release unless
the code has had major additions or changes in the future.   I will
instead post the patches to the project site with a single post on this
list to point to the patches.

I will post patch series when x86_64 is finished and I have completed my
rewrite of traps_32.c and traps_64.c -- Linux needs nested TSS gates over
all the exceptions so the system can handle nested exceptions and switch
to a known good stack during faults.  At present, what's there is ok but
not as resilient as it could be.

Jeff



#include <unistd.h>
#include <stdio.h>
#include <string.h>

#define TESTING 1

unsigned char buffer[8192];
unsigned char filename[64];

int output_comments(FILE *fl, int j)
{
    fprintf(fl, "\n");
    return 0;
}

int main(int argc, char *argv[])
{
    register int i = 1, j;
    register FILE *fp = NULL, *fl, *fs;
    char *s, *p;

    while (s = fgets(buffer, 8192, stdin))
    {
       if (!strncmp(s, "diff", 4))
         continue;

       if (!strncmp(s, "---", 3))
       {
          if (fp)
          {
             i++;
             fclose(fp);
          }

          sprintf(filename, "%i.patch", i);
          fp = fopen(filename, "wb");
          if (!fp)
          {
             printf("file open error [%s]\n", filename);
             return 1;
          }

          p = strchr(s, '/');
          if (p)
          {
             fprintf(fp, "--- a");
             fprintf(fp, "%s", p);
          }
          else
             fprintf(fp, "%s", s);
          continue;
       }

       if (!strncmp(s, "+++", 3))
       {
          p = strchr(s, '/');
          if (p)
          {
             fprintf(fp, "+++ b");
             fprintf(fp, "%s", p);
          }
          else
             fprintf(fp, "%s", s);
          continue;
       }

       if (fp);
          fprintf(fp, "%s", s);
    }
    if (fp)
       fclose(fp);

    fs = fopen("mailer", "wb");
    if (!fs)
    {
       printf("file open error [mailer]\n");
       return 1;
    }

    for (j=1; j <= i; j++)
    {
       sprintf(filename, "%i.patch", j);
       fp = fopen(filename, "rb");
       if (!fp)
       {
          printf("file open error [%s]\n", filename);
          return 1;
       }

       sprintf(filename, "%i.final", j);
       fl = fopen(filename, "wb");
       if (!fl)
       {
          printf("file open error [%s]\n", filename);
          return 1;
       }
       fprintf(fs, "sendmail -f jmerkey@wolfmountaingroup.com -t < %s\n",
               filename);

#if TESTING
       fprintf(fl, "To:jeff@wolfmountaingroup.com\n");
#else
       fprintf(fl, "To:linux-kernel@vger.kernel.org\n");
#endif
       fprintf(fl, "From:jmerkey@wolfmountaingroup.com\n");
       fprintf(fl, "Subject:[PATCH %s %i/%i] mdb: ",
               argv[1] ? argv[1] : "", j, i);

       output_comments(fl, j);

       fprintf(fl, "Signed-off-by: Jeffrey Vernon Merkey "
                   "(jmerkey@wolfmountaingroup.com)\n\n");

       while (s = fgets(buffer, 8192, fp))
          fprintf(fl, "%s", s);

       fclose(fp);
       sprintf(filename, "%i.patch", j);
       unlink(filename);

       fclose(fl);
    }
    fclose(fs);
    chmod("mailer", 755);
    return 0;
}

RE: [PATCH 2.6.27-rc5 1/29] mdb: export ioapic read routines and detected ioapic count

[Halevy, Benny]

Cool.  If you find git-send-email too low-level, feel
free to use my convenience script, git-send-patch:
http://git.bhalevy.com/git/gitweb.cgi?p=git-tools.git;a=blob_plain;f=git-send-patch;hb=HEAD
that helps automate the patch sending process even further
in particular it knows to wait between each email
so that they arrive to the list (approx.) in order.
(Otherwise I found that Thundermail might get confused
when trying to thread them together)
Note: don't forget to keep the angle brackets surrounding
the message-id for the in-reply-to parmaeter...

Benny

-----Original Message-----
From: jmerkey@wolfmountaingroup.com [mailto:jmerkey@wolfmountaingroup.com]
Sent: Mon 2008-09-01 16:39
To: Halevy, Benny
Cc: jmerkey@wolfmountaingroup.com; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.27-rc5 1/29] mdb: export ioapic read routines and      detected ioapic count
 
> Jeff, general comment: can you please send your patches as replies
> to a leading message so they all be linked as a single thread?
> Threading them together is helpful for maintaining several
> versions of your patchset and it's simpler to ignore if one's
> not really interested in this topic at all.
>
> Benny
>

Hi Benny,

I was already scolded about this by a few folks.  I had not located the
git email programs when I submitted this project and I wrote something
myself to submit them.  (see attached).  I have thrown the program in the
trash I wrote to do this and moved to git.

Now I have reviewed the git clients and patch tools and I understand and
will use git and I see now why git works this way with the reply chain. I
will not be submitting patch series on this list for every release unless
the code has had major additions or changes in the future.   I will
instead post the patches to the project site with a single post on this
list to point to the patches.

I will post patch series when x86_64 is finished and I have completed my
rewrite of traps_32.c and traps_64.c -- Linux needs nested TSS gates over
all the exceptions so the system can handle nested exceptions and switch
to a known good stack during faults.  At present, what's there is ok but
not as resilient as it could be.

Jeff



#include <unistd.h>
#include <stdio.h>
#include <string.h>

#define TESTING 1

unsigned char buffer[8192];
unsigned char filename[64];

int output_comments(FILE *fl, int j)
{
    fprintf(fl, "\n");
    return 0;
}

int main(int argc, char *argv[])
{
    register int i = 1, j;
    register FILE *fp = NULL, *fl, *fs;
    char *s, *p;

    while (s = fgets(buffer, 8192, stdin))
    {
       if (!strncmp(s, "diff", 4))
         continue;

       if (!strncmp(s, "---", 3))
       {
          if (fp)
          {
             i++;
             fclose(fp);
          }

          sprintf(filename, "%i.patch", i);
          fp = fopen(filename, "wb");
          if (!fp)
          {
             printf("file open error [%s]\n", filename);
             return 1;
          }

          p = strchr(s, '/');
          if (p)
          {
             fprintf(fp, "--- a");
             fprintf(fp, "%s", p);
          }
          else
             fprintf(fp, "%s", s);
          continue;
       }

       if (!strncmp(s, "+++", 3))
       {
          p = strchr(s, '/');
          if (p)
          {
             fprintf(fp, "+++ b");
             fprintf(fp, "%s", p);
          }
          else
             fprintf(fp, "%s", s);
          continue;
       }

       if (fp);
          fprintf(fp, "%s", s);
    }
    if (fp)
       fclose(fp);

    fs = fopen("mailer", "wb");
    if (!fs)
    {
       printf("file open error [mailer]\n");
       return 1;
    }

    for (j=1; j <= i; j++)
    {
       sprintf(filename, "%i.patch", j);
       fp = fopen(filename, "rb");
       if (!fp)
       {
          printf("file open error [%s]\n", filename);
          return 1;
       }

       sprintf(filename, "%i.final", j);
       fl = fopen(filename, "wb");
       if (!fl)
       {
          printf("file open error [%s]\n", filename);
          return 1;
       }
       fprintf(fs, "sendmail -f jmerkey@wolfmountaingroup.com -t < %s\n",
               filename);

#if TESTING
       fprintf(fl, "To:jeff@wolfmountaingroup.com\n");
#else
       fprintf(fl, "To:linux-kernel@vger.kernel.org\n");
#endif
       fprintf(fl, "From:jmerkey@wolfmountaingroup.com\n");
       fprintf(fl, "Subject:[PATCH %s %i/%i] mdb: ",
               argv[1] ? argv[1] : "", j, i);

       output_comments(fl, j);

       fprintf(fl, "Signed-off-by: Jeffrey Vernon Merkey "
                   "(jmerkey@wolfmountaingroup.com)\n\n");

       while (s = fgets(buffer, 8192, fp))
          fprintf(fl, "%s", s);

       fclose(fp);
       sprintf(filename, "%i.patch", j);
       unlink(filename);

       fclose(fl);
    }
    fclose(fs);
    chmod("mailer", 755);
    return 0;
}