Linux-Development-Sys Digest #656, Volume #7      Mon, 6 Mar 00 16:13:14 EST

Contents:
  Re: Solaris NFS incompatibility (David T. Blake)
  Re: mmap and PCI driver (Brett Johnson)
  Help with printk (Nils Wygant)
  Re: Struct size and allocate problem! need help. (Thomas F. Drescher)
  Re: Struct size and allocate problem! need help. ("P.G.Hamer")
  Re: What's GNU/Linux? (Nelson Minar)
  Re: Linux and DVD (Nix)
  Re: switch from protected mode to real mode in kernel (Nix)
  Re: unmmaped area? (Fabrice Peix)
  Re: Help with printk (Fabrice Peix)
  ISA SOUND CARD? (John-Paul)
  Re: Solaris NFS incompatibility ("Scott L. Burson")
  Re: Struct size and allocate problem! need help. (Scott Lurndal)
  Re: Binary compatibility: what kind of crack are they smoking? (Colin Watson)
  Re: What's GNU/Linux? (David Wragg)
  enqueue and dequeue ("Aurelie Fonteny")
  LILO and GRUB: where do you pick disk geometry from? (repost) 
([EMAIL PROTECTED])

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Solaris NFS incompatibility
Date: 6 Mar 2000 14:49:46 GMT
Reply-To: [EMAIL PROTECTED]

Scott L. Burson <[EMAIL PROTECTED]> wrote:
> Greetings all,
> 
> It has become clear to me that there is a subtle
> incompatibility between the Linux 2.2 NFS client and the Solaris
> NFS server (at least, the one in Solaris 2.5.1).

This is a Solaris server bug. It has been discussed numerous
times on this newsgroup as well as in the linux nfs mailing
archive at www.sourceforge.org (nfs).

There is a patch at Sun's web site.

-- 
Dave Blake
[EMAIL PROTECTED]

------------------------------

From: Brett Johnson <[EMAIL PROTECTED]>
Subject: Re: mmap and PCI driver
Date: Mon, 06 Mar 2000 10:28:43 -0700
Reply-To: [EMAIL PROTECTED]

Steve Haynal wrote:
> 
> I'm using mmap to remap PCI configuration registers/memory into user space.
> This works fine. Now I'm adding IRQ support to my driver. Part of the IRQ
> handler requires that the kernel driver also accesses a now mapped to user
> space configuration register to clear pending interrupts. Is it possible
> for both user space and kernel space to have access to the same memory? If
> so, how is it done?

Take a look at the kernel "ioremap" function (mm/ioreadmap.c).  It takes an
arbitrary physical address (i.e. your PCI card's config space), and maps it
to kernel virtual memory space (kinda like mmap in user space).

Cheers!
-- 
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company

------------------------------

From: [EMAIL PROTECTED] (Nils Wygant)
Subject: Help with printk
Date: Mon, 06 Mar 2000 17:42:09 GMT

I nee some help.......

I'm writing a device driver and  I can't see any of the debugging
printk's that are made from within the module code.  Printk is the kernel
equivalent to printf but it sends it's output to the console.  I've read
that when using printk's from within X  (i'm using RedHat 6.0 and Gnome)
 you won't see the output because ofX's use of "Virtual" terminals......???
 I did a man on xterm and saw a -C option but this had no effect. 
 It's suppose to redirect all Console output to the active "virtual" terminal. 
It also says that it's not guaranteed to work.   o-well....   this was the case it 
seems. 
 Anyway, does anyone have any suggestions?

Thanks,
-Nils

------------------------------

From: Thomas F. Drescher <[EMAIL PROTECTED]>
Crossposted-To: 
alt.os.linux,comp.os.linux.development.apps,comp.unix.sco.misc,comp.unix.sco.programmer,comp.unix.unixware.misc,tw.bbs.comp.linux
Subject: Re: Struct size and allocate problem! need help.
Date: Sat, 04 Mar 2000 05:42:26 GMT

Hi Jaron,

IMHO Peter is right with his statement. Be portable. BTW did u try=20
this one:

typedef struct A {
        unsigned char    a1[ 1 ];
        unsigned char    a2[ 1 ];
        unsigned short   a3;
        unsigned short   a4;
        unsigned long    a5;
    } A;

So what happens here is that the compiler does NOT make a 16-bit=20
alignment of the chars. I didn't try but i bet its size is 10 now=20
(assumed long is 4 bytes). But the way to dereference a1 and a2 is=20
different now.

So - unless you have to process binary files of different processor=20
types - let the compiler do, =84he=93 knows how to do right on the=20
appropriate machine.

There's much more to say about portability between machines, be very=20=

careful. I wrote once some routines to process VAX/VMS binary files on=20=

a HP/UX machine. There i had to change the low order high order=20
endians of ints and to convert the 4-byte IEEE-something floats.

What i learned e.g. is that the HP UNIX machine can use POINTERS only=20=

on 4-byte aligned locations (otherwise: core dump...))-: So it is not=20=

possible to access the a2 directly by pointer. But you can access the=20=

structure by pointer and assign the values of the structure members.

Hope all clearlyness has been removed now,  ;-)
regards, Thomas

>>>>>>>>>>>>>>>>>> Urspr=FCngliche Nachricht <<<<<<<<<<<<<<<<<<

Am 03.03.00, 13:54:51, schrieb [EMAIL PROTECTED] (Peter) zum=20=

Thema Re: Struct size and allocate problem! need help.:


> No, that's not a good doing, and i am shure you will get problems in
> the future if going this, nonportable way!
> The real problem came up from the hardware-processor and belongs to
> the alligment. Most (and as long as i know) all intel ones need a
> 4-byte alligment addressing structs. So the compiler filled it to a
> multiple of 4 anyway. If you have asignmetproblems with other data,
> cast it like struct0_data =3D (struct0 *)data.
> Use a protable way! you and all the others will thanks you!
> Peter

> On 2 Mar 2000 06:22:01 GMT, "Jaron" <[EMAIL PROTECTED]> wrote:

> >ThankX all for suggestions.
> >
> >At this point. what I worry about is the portability ?
> >Because I want this program works for many UNIX environment like
> >SCO UNIX, UnixWare, UNIX SVR4.2 and Linux...
> >
> >So if I change this structure as below( change unsigned long to 4=20=

unsigned
> >char)
> >
> >     struct    a {
> >         unsigned char    a1;
> >         unsigned char    a2;
> >         unsigned short    a3;
> >         unsigned short    a4;
> >         /*unsigned long    a5;*/
> >         unsigned char a5[4];
> >     };
> >
> >Do you think this is better ?
> >
> >
> >*------------------------------------------------*
> >I use the structure as below:
> >
> >uchar RXBuf[2048];
> >
> >void F1 ((uchar *) P)
> >{
> > ..
> > len =3D recvfrom (sock, (char *)RxBuf, sizeof (RxBuf), 0, .....);
> > ...
> >
> > bcopy (RxBuf, P, len);
> > ...
> >}
> >
> >void F2(void)
> >{
> > F1 ((uchar *) a );
> >
> > ...
> >}
> >
> >
> >




------------------------------

From: "P.G.Hamer" <[EMAIL PROTECTED]>
Crossposted-To: 
alt.os.linux,comp.os.linux.development.apps,comp.unix.sco.misc,comp.unix.sco.programmer,comp.unix.unixware.misc,tw.bbs.comp.linux
Subject: Re: Struct size and allocate problem! need help.
Date: Mon, 06 Mar 2000 18:05:03 +0000

Charles Bryant wrote:

> In article <[EMAIL PROTECTED]>,
> P.G.Hamer <[EMAIL PROTECTED]> wrote:
> >Charles Bryant wrote:
> >> There's no inconsistencey. All of char, short, and long can be 32
> >> bits, in which case sizeof(long)==sizeof(short)==sizeof(char)==1.
> >
> >Can you elaborate on this.
> >
> >My dated 2nd edition of K&R states that sizeof() gives the size in /bytes/.
>
> Where?

p204 under A7.4.8 Sizeof Operator 1st sentence.

> >It also states that sizeof(char)==1.

p204 under A7.4.8 Sizeof Operator 3rd sentence

> >While I'm not certain that these two statements are necessarily mutually
> >consistent, it does suggest that sizeof(32bit-type) == 4.
>
> It would. But a char can be bigger than 8 bits, and on some
> processors all types are 32-bit (i.e. char, short, int, long).

Agreed, that's why I said `While I'm not certain that these two statements
are necessarily mutually consistent'. They only seem reconcilable in this
case if a byte is 32-bits wide.

Looks like this is true, although I'm uncertain of its date
http://www.lysator.liu.se/c/rat/c3.html#3-3-3-4
says:
It is fundamental to the correct usage of functions such as malloc and
fread that sizeof (char) be exactly one.  In practice, this means that a byte
in C terms is the smallest unit of storage, even if this unit is 36 bits wide;
and all objects are comprised of an integral number of these smallest units.

Peter


------------------------------

Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: What's GNU/Linux?
From: Nelson Minar <[EMAIL PROTECTED]>
Date: 06 Mar 2000 10:03:03 -0800

I think Stallman's "GNU/Linux" thing is obnoxious too, but let's not
get confused about one important point:

grant@nowhere. (Grant Edwards) writes:
> My point: Gcc is a result of the open-source software movement, not
> the cause of it.

Sure. But the sheer existence of the open-source software movement is
due in large part to Stallman's years of evangelism. He created a lot
of free software, he articulated the reasons for free software, he
organized free software people. He led by example, he wrote a lot of
the code in gcc.

The thing I've regretted about the whole stupid "GNU/Linux" thing is
that it's become divisive, encouraging people to find difference when
there is largely similarity.

                                                     [EMAIL PROTECTED]
.       .      .     .    .   .  . . http://www.media.mit.edu/~nelson/

------------------------------

From: Nix <$}xinix{[email protected]>
Subject: Re: Linux and DVD
Date: 06 Mar 2000 07:35:27 +0000

Anders Larsen <[EMAIL PROTECTED]> writes:

> MS wants to see your source code!  Well, with open source, thats a
> legitimate request - but do we really expect MS to honour the GPL?

If they want to dishonour it, well, they already *have* the source code.

-- 
`> KNOWLEDGE AND SKILLS
 You must have some, but I don't see any evidence of it.'
   --- Craig Hardie flames a luser recruitment consultant
       advertising `Microsoft based solutions' on uk.comp.os.linux

------------------------------

From: Nix <$}xinix{[email protected]>
Subject: Re: switch from protected mode to real mode in kernel
Date: 06 Mar 2000 07:53:37 +0000

[EMAIL PROTECTED] writes:

> Does anyone have code that would show how to switch from protected mode
> back to 8086 compatible real mode that x86 processors always start in?
> I would be doing this at the end of a shutdown before the kernel would
> otherwise do its final halt/reboot.

See linux/arch/i386/process.c:reboot_setup() and code following.

-- 
`> KNOWLEDGE AND SKILLS
 You must have some, but I don't see any evidence of it.'
   --- Craig Hardie flames a luser recruitment consultant
       advertising `Microsoft based solutions' on uk.comp.os.linux

------------------------------

From: Fabrice Peix <[EMAIL PROTECTED]>
Subject: Re: unmmaped area?
Date: Mon, 06 Mar 2000 19:44:23 +0100

Takeyasu Wakabayashi wrote:
> 
> Fabrice Peix <[EMAIL PROTECTED]> writes:
> 
> > I thing you  are wrong , paging system is made bye processor and all the
> > memory
> > is manage by MMU and so paging...
> 
> Then why do you have `struct page' structure and `mem_map' list
> made thereof in the Linux kernel?
> 
> --
>     Takeyasu Wakabayashi
>     Faculty of Economics, Toyama University
>     [EMAIL PROTECTED]
This structure is use for store information on page because the MMU
can't store all this information.
look at include/asm-i386/pgtable.h for more information on page table.

        Bye and Ooops.

------------------------------

From: Fabrice Peix <[EMAIL PROTECTED]>
Subject: Re: Help with printk
Date: Mon, 06 Mar 2000 19:47:29 +0100

Nils Wygant wrote:
> 
> I nee some help.......
> 
> I'm writing a device driver and  I can't see any of the debugging
> printk's that are made from within the module code.  Printk is the kernel
> equivalent to printf but it sends it's output to the console.  I've read
> that when using printk's from within X  (i'm using RedHat 6.0 and Gnome)
>  you won't see the output because ofX's use of "Virtual" terminals......???
>  I did a man on xterm and saw a -C option but this had no effect.
>  It's suppose to redirect all Console output to the active "virtual" terminal.
> It also says that it's not guaranteed to work.   o-well....   this was the case it 
>seems.
>  Anyway, does anyone have any suggestions?
> 
> Thanks,
> -Nils
You can use xconsole or look in the file /var/log/messages ....

------------------------------

From: John-Paul <[EMAIL PROTECTED]>
Subject: ISA SOUND CARD?
Date: Mon, 06 Mar 2000 13:01:04 -0800

Hey Everyone,

I have a MV Pro Audio Spectrum 16 sound card.  How do I get Linux to
recognize it??

J.P

------------------------------

From: "Scott L. Burson" <[EMAIL PROTECTED]>
Subject: Re: Solaris NFS incompatibility
Date: Mon, 06 Mar 2000 10:55:20 -0800

lamarqu1 wrote:
> 
> The problem does not come from the Linux client but from the Solaris
> server. A patch from SUN exists to correct this problem.

No kidding!  Okay, thanks.

-- Scott

------------------------------

From: [EMAIL PROTECTED] (Scott Lurndal)
Crossposted-To: 
alt.os.linux,comp.os.linux.development.apps,comp.unix.sco.misc,comp.unix.sco.programmer,comp.unix.unixware.misc,tw.bbs.comp.linux
Subject: Re: Struct size and allocate problem! need help.
Date: 6 Mar 2000 19:29:26 GMT
Reply-To: [EMAIL PROTECTED]

In article <[EMAIL PROTECTED]>, "Jaron" <[EMAIL PROTECTED]> writes:
|> ThankX all for suggestions.
|> 
|> At this point. what I worry about is the portability ?
|> Because I want this program works for many UNIX environment like
|> SCO UNIX, UnixWare, UNIX SVR4.2 and Linux...

For Unixware, Solaris, SVR4.* and Linux - look at

$ man -k xdr

for information about external-data-representation (as used by
SUN RPC).

No structure definition will be binary compatible between 
dissimilar architectures (e.g. mips vs. ia32 vs. sparc vs. alpha),
so XDR was developed to provide an architecture independent data
representation.  'tis a bit verbose, but useful.

Alternative to xdr is simply to use ISO-8859-1 octets
to represent the data (and convert back to binary with the
appropriate conversion function - e.g. strtoul, strtod, et. al.)

scott

------------------------------

From: [EMAIL PROTECTED] (Colin Watson)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: 6 Mar 2000 19:49:16 GMT

Donovan Rebbechi <[EMAIL PROTECTED]> wrote:
>On 6 Mar 2000 12:30:31 GMT, Colin Watson wrote:
>>GNOME, absolutely, but 
>
>In fact Applixware already links against GTK.

Hm, OK, yes, GTK and GNOME are both LGPLed. My fault for not reading
closely enough.

>>But, in any case, section 6a of the QPL states that all Qt-linked
>>applications must be open-source, 
>
>That or the licensee must pay a license fee.

Clearly one can always break the terms of a licence with special
permission from the licensor. It's not clear why the Qt developers would
want to give such permission if they really believe in the terms of
their licence, though I suppose money talks. :( I find it hard to
imagine, say, the FSF giving anyone permission to distribute software
linked against any of their GPLed software, though perhaps TrollTech are
less committed.

-- 
Colin Watson                                           [[EMAIL PROTECTED]]
"And after the fire there came a still small voice ..."

------------------------------

From: David Wragg <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: What's GNU/Linux?
Date: 06 Mar 2000 19:52:50 +0000

[EMAIL PROTECTED] (Alexander Viro) writes:
> In article <[EMAIL PROTECTED]>,
> Edward Rosten  <[EMAIL PROTECTED]> wrote:
> >I agree with RMS on this one. Most of what we know as 'Linux' is
> >actually GNU stuff.
> 
> <sarcasm>
> Like X, for one, right? Or Perl. Or TeX. Or MTA-of-your-choice.
> Or BIND. Or trn. Or <arbitrary-network-related-stuff>. Or vi. Or...
> </sarcasm>

Early GNU documents by RMS (they can probably be found on www.gnu.org)
proposing GNU explicitly include X and TeX in the system. Remember,
being part of GNU, being developed by the FSF, and being GPLed are
completely independent properties.


David Wragg

------------------------------

From: "Aurelie Fonteny" <[EMAIL PROTECTED]>
Subject: enqueue and dequeue
Date: Mon, 6 Mar 2000 14:01:05 -0600


In include/net/pkt_sched.h, a structure Qdisc is defined : it defines int
*enqueue() and struct skbuff *  (*dequeue(...)),...
In /net/core/dev.c enqueue is used (routine dev_queue_xmit()), but I can't
see where q->enqueue is initialized (what function does enqueue refer to?
Where is it defined?)

Thanks for your answer.
Aurelie

PS : This is kernel 2.2.
You can have the code source here :
http://zaphod.redwave.net/linux/kernel-2.2/



------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: LILO and GRUB: where do you pick disk geometry from? (repost)
Date: 07 Mar 2000 07:52:05 +0000

Hi!

I tried to solve system boot problem using both LILO and GRUB. System
is P90, with Phoenix BIOS 4.04 and Fujitsu's MPB3021AT hard drive, and
only Linux is there. Manufacturer data says that Bios setting should
be Cyl/Head/sec = 4470/15/63. BIOS has LBA mode enabled and it
autodetects disk with C/H/S=4470/15/63. OS images are on the partition
that is 1023 cylinders, and it's a first partition on the drive. Boot
sequence in BIOS is set to be A: then C:.

LILO story (quite interesting!): ------------------------

In lilo.conf I specified "linear" option, and tried switching on/off
the "compact" option.

When I turn on the system, it gets to "LI" and stops. NOW THIS: when I
first boot using a floppy, take the floppy out and subsequently
shutdown the system to reboot, LILO prompt appears. Now, I can press
hardware RESET button many times, the boot will always be
successful. Interestingly, disk geometry during the boot is reported
as 558/120/63. But, THE FIRST TIME I TURN PC OFF, and try to boot, it
gets to "LI" and stops. I tried to explicitely set disk geometry to
real values, then reported (558...) but nothing worked.

Conclusion: 
It looks as that after the first successful boot somenone
(BIOS?Linux?) somehow sets up proper hard disk geometry parameters and
stores them in some volatile RAM location that preserves its content
on RESET, but loses it on power down. LILO works flawlessly once
floppy has been accessed but fails when it has to do it on its own.


GRUB story:

After LILO failure, I decided to try GRUB. The behaviour is similar: I
created a boot floopy containing only "stage1" loader. When I boot
with that floppy, I get a GRUB prompt and then commands:

kernel (hd0,0)/vmlinuz
boot

make it boot the system effortlessly. Then I used "install" command to
make it boot directly from the hard disk, using stage1_lba. After the
reset, GRUB reported:

LBA Error

QUESTION:

I read in Large-Disk HOWTO that these problems are caused by
incompatibility of various standards regarding representation of disk
geometry. However, it did not give any hint about overcoming this
problem. If the boot process IS possible directly from the hard disk,
without a floppy, obviously there is a set of geometry parameters that
works. I guess the solution is to find right geometry parameters. Is
there some systematic procedure that leads to successful guess?  Does
anyone know of some volatile RAM location, that does not get
initialized on hardware RESET, and might contain disk geometry params
I look for? Could it be in CMOS chip that has a real-time clock?

Thanks a lot.

Milan

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.development.system) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to