dmidecode-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: FW: [dmidecode] dmidecode for DOS?


From: Anderson, Ian
Subject: FW: FW: [dmidecode] dmidecode for DOS?
Date: Sun, 11 Sep 2005 08:29:39 -0400

Success, sort of.  I was able to get dmidecode to successfully compile under
DJGPP and run under FreeDOS, please see attached util.c for my changes and
dmitest.txt for the output.  Unfortunately the only way I was able to get it
to compile was to disable all the command line options (dmiopt.c and bits in
dmidecode.c), so I still need to work on that.

Ian

On Sun, 2005-09-11 at 06:54 -0400, Anderson, Ian wrote:
>  
> -----Original Message-----
> From: ...On Behalf Of Jean Delvare
> Sent: Sunday, September 11, 2005 4:16 AM
> To: address@hidden
> Subject: Re: [dmidecode] dmidecode for DOS?
> 
> Hi Ian,
> 
> [Ian Anderson]
> > Got in touch with Eric Auer over at FreeDOS and his suggestion was 
> > to use _farpeekb or DPMI access.
> > 
> > http://www.delorie.com/djgpp/doc/libc-2.02/libc_270.html
> > 
> > or
> > 
> > http://www.delorie.com/djgpp/doc/libc-2.02/libc_8.html
> > 
> > _farpeekb seems a lot simpler.  If I am reading your code correctly 
> > (50/50 chance of that), and recall the compiler error message it 
> > appears there is only one line in mem_chunk -- mmp=mmap(0,
> > mmoffset+len, PROT_READ, MAP_SHARED, fd, base-mmoffset); that needs 
> > mmoffset+to
> > be changed,
> 
> It's a bit more complex than that. There are two memory access 
> implementations in dmidecode currently, one using lseek+read, one 
> using mmap. Only one is selected at compilation time (although I plan 
> to move the choice to run time instead.) Both rely on /dev/mem 
> ultimately, that is, the memory is accessed as a file. In the case of 
> DOS we will instead be accessing the low memory directly, so a lot of code
can go away.
> 
> > unfortunately _farpeekb takes a different number of arguements, so 
> > where to start? :S
> 
> I'm taking my chance. Note that I have no DOS/DJGPP environment to 
> test the code, so read it as "that's where I would start" and try to 
> fix the problems yourself from there.
> 
> #include <sys/farptr.h>
> 
> void *mem_chunk(size_t base, size_t len, const char *devmem) {
>       void *p;
>       size_t i;
> 
>       if((p=malloc(len))==NULL)
>       {
>               perror("malloc");
>               return NULL;
>       }
>       
>       _farsetsel(_dos_ds);
>       for(i=0; i<len; i++)
>       {
>               *((char *)p+i)=_farnspeekb(base+i);
>       }
> 
>       return p;
> }
> 
> Note that the code above will trigger a warning about devmem not being 
> used, but you can ignore it safely.
> 
> This is certainly not the most efficient method (a direct memcpy from 
> the lower memory range would be better) but that might work. Maybe 
> DPMI can do that faster but I wouldn't know where to start. A more 
> simple optimization would be to use _farnspokel instead of 
> _farnspeekb, you just have to allocate a few more bytes. Note that 
> there may be memory alignment issues though.
> 
> void *mem_chunk(size_t base, size_t len, const char *devmem) {
>       void *p;
>       size_t i;
> 
>       if(len%sizeof(long))
>       {
>               len+=sizeof(long)-len%sizeof(long);
>       }
> 
>       if((p=malloc(len)==NULL)
>       {
>               perror("malloc");
>               return NULL;
>       }
>       
>       _farsetsel(_dos_ds);
>       for(i=0; i*sizeof(long)<len; i++)
>       {
>               *((long *)p+i)=_farnspeekb(base+i*sizeof(long));
>       }
> 
>       return p;
> }
> 
> Again I couldn't try this code so it's most certainly bogus, but at 
> least now you have an idea where to start :)
> 
> --
> Jean Delvare
> 
> 
> _______________________________________________
> http://lists.nongnu.org/mailman/listinfo/dmidecode-devel

Attachment: UTIL.C
Description: Text Data

Attachment: DMITEST.TXT
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]