[Top][All Lists]
[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
UTIL.C
Description: Text Data
DMITEST.TXT
Description: Text document