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)
 {
--

[ message continues ]

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


--

[ message continues ]

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);
     ...
[ message continues ]