Re: Linux kernel modules development in C++

[Peter Samuelson]

[Igmar Palsenberg]
> I think there was a thread about C++ in the kernel a while ago, I'll
> see if I can find it.

Understatement of the year

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Module unresolved symbol on 2.4.0-test8 SMP

[Mike Galbraith]

On Thu, 28 Sep 2000, Keith Owens wrote:

> On Wed, 27 Sep 2000 14:11:30 -0500 (CDT), 
> [EMAIL PROTECTED] (Sam Watters) wrote:
> >[root@porsche13 themod-dev]# insmod themod.o
> >themod.o: unresolved symbol write_lock
> >themod.o: unresolved symbol read_lock
> > 
> >gcc -Wall -Wstrict-prototypes -fomit-frame-pointer -pipe -march=i686
> >-fno-strict-aliasing  -D__SMP__ -DMODULE -D__KERNEL__ -DLINUX -Dlinux 
> >-DDEBUG -I../../../include -c themod.c 
> 
> Compile with -O2 otherwise functions will not be inlined.  The Linux
> kernel requires -O2, it is not an option.  I'm surprised this is not in
> the FAQ.

Adding -finline should fix it too.
(if someone really wants to build unoptimized).

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

early initialization of device "X" is deferred

[r00t the LiNuXeRRR]

Hello all,

[Subject] is an message who is appear at the boot time. Here is
the parts of dmesg:

.

TCP: Hash tables configured (ehash 131072 bhash 65536)
IPv4 over IPv4 tunneling driver
early initialization of device tunl0 is deferred ***
GRE over IPv4 tunneling driver
early initialization of device gre0 is deferred 
Linux IP multicast router 0.06 plus PIM-SM
NET4: Linux IPX 0.38 for NET4.0

.

Detected scsi disk sda at scsi0, channel 0, id 6, lun 0
scsi : detected 1 SCSI generic 1 SCSI disk total.
ncr53c825-0-<6,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 8)
SCSI device sda: hdwr sector= 512 bytes. Sectors= 4235629 [2068 MB] [2.1
GB]
early initialization of device teql0 is deferred ***
NET4: Ethernet Bridge 007 for NET4.0
early initialization of device brg0 is deferred 
Equalizer1996: $Revision: 1.2.1 $ $Date: 1996/09/22 13:52:00 $ Simon Janes
(sim
PPP: version 2.3.7 (demand dialling)

What can i do to resolve this problem?

Thanx,
Cosmin


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Socket Interface

[Peter Samuelson]

[Eric Chen]
> I have brought up a PC running Linux 6.2.

There is no Linux 6.2.  The newest version is a prerelease of 2.4.0.

Unlike other OSes you may be familiar with (e.g. FreeBSD), there is no
de facto standard distribution of kernel and apps -- there are half a
dozen major players and hundreds of minor ones, three quarters of which
are "Red Hat + some nifty add-on or service".

In any case, I suggest you look at a client for the 'finger' protocol,
which is just about as simple a TCP transaction as you can get.  Note
that the server is inetd-driven so has no networking code of its own.
I can't think of a simple TCP daemon that *isn't* inetd-driven, though.

If your Linux distribution is Debian-derived:

  $ dpkg -S /usr/bin/finger
  finger: /usr/bin/finger

So the package is called 'finger':

  $ cd /var/tmp; apt-get source finger
  Reading Package Lists... Done
  Building Dependency Tree... Done
  Need to get 29.2kB of source archives.
  Get:1 http://http.us.debian.org woody/main bsd-finger 0.16-3 (dsc) [667B]
  Get:2 http://http.us.debian.org woody/main bsd-finger 0.16-3 (tar) [24.6kB]
  Get:3 http://http.us.debian.org woody/main bsd-finger 0.16-3 (diff) [3894B]
  Fetched 29.2kB in 3s (9.4kB/s)
  dpkg-source: extracting bsd-finger in bsd-finger-0.16

If your distribution is not Debian-derived, I don't know how to get the
source.  Ask your vendor.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

3c985 (aka acenic) gigabit support broken in test9pre7?

[Olivier Galibert]

I compiled in the support for the 3c985, but, somehow, the kernel does
not seem to see the card.

Dual p3, asus p2b-d motherboard, test9pre7+reiserfs.

  OG.



slice cutoff: 731.88 usecs.
Getting VERSION: 40011
Getting VERSION: 40011
Getting ID: 100
Getting ID: e00
Getting LVT0: 8700
Getting LVT1: 400
enabled ExtINT on CPU#0
ESR value before enabling vector: 
ESR value after enabling vector: 
CPU present map: 3
Booting processor 1/0 eip 2000
Setting warm reset code and vector.
1.
2.
3.
Asserting INIT.
Waiting for send to finish...
+Deasserting INIT.
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1.
After apic_write.
Startup point 1.
Waiting for send to finish...
+Initializing CPU#1
CPU#1 (phys ID: 0) waiting for CALLOUT
Sending STARTUP #2.
After apic_write.
Startup point 1.
Waiting for send to finish...
+After Startup.
Before Callout 1.
After Callout 1.
CALLIN, before setup_local_APIC().
masked ExtINT on CPU#1
ESR value before enabling vector: 
ESR value after enabling vector: 
Calibrating delay loop... 1402.47 BogoMIPS
Stack at about dfff7fbc
OK.
CPU1: Intel Pentium III (Coppermine) stepping 01
CPU has booted.
Before bogomips.
Total of 2 processors activated (2801.66 BogoMIPS).
Before bogocount - setting activated=1.
Boot done.
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
Synchronizing Arb IDs.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-13, 2-18, 2-20, 2-21, 2-22, 2-23 not 
connected.
..TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
number of MP IRQ sources: 15.
number of IO-APIC #2 registers: 24.
testing the IO APIC...

IO APIC #2..
 register #00: 0200
...: physical APIC id: 02
 register #01: 00170011
... : max redirection entries: 0017
... : IO APIC version: 0011
 register #02: 
... : arbitration: 00
 IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  100   0   00000
 01 003 03  000   0   01139
 02 003 03  000   0   01131
 03 003 03  000   0   01141
 04 003 03  000   0   01149
 05 000 00  100   0   00000
 06 003 03  000   0   01151
 07 003 03  000   0   01159
 08 003 03  000   0   01161
 09 003 03  000   0   01169
 0a 000 00  100   0   00000
 0b 000 00  100   0   00000
 0c 003 03  000   0   01171
 0d 000 00  100   0   00000
 0e 003 03  000   0   01179
 0f 003 03  000   0   01181
 10 003 03  110   1   01189
 11 003 03  110   1   01191
 12 000 00  100   0   00000
 13 003 03  110   1   01199
 14 000 00  100   0   00000
 15 000 00  100   0   00000
 16 000 00  100   0   00000
 17 000 00  100   0   00000
IRQ to pin mappings:
IRQ0 -> 2
IRQ1 -> 1
IRQ3 -> 3
IRQ4 -> 4
IRQ5 -> 19
IRQ6 -> 6
IRQ7 -> 7
IRQ8 -> 8
IRQ9 -> 9
IRQ10 -> 17
IRQ11 -> 16
IRQ12 -> 12
IRQ14 -> 14
IRQ15 -> 15
 done.
calibrating APIC timer ...
. CPU clock speed is 701.6615 MHz.
. host bus clock speed is 100.2372 MHz.
cpu: 0, clocks: 1002372, slice: 334124
CPU0
cpu: 1, clocks: 1002372, slice: 334124
CPU1
checking TSC synchronization across CPUs: passed.
Setting commenced=1, go go go
PCI: PCI BIOS revision 2.10 entry at 0xf0730, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/122e] at 00:04.0
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
P6 Microcode Update Driver v1.07
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
loop: enabling 8 loop devices
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 21
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
hda: IBM-DPTA-372050, ATA DISK drive
hdc: Maxtor 96147U8, ATA DISK drive
hdd: Maxtor 96147U8, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=2495/255/63, UDMA(33)
hdc: 120060864 sectors (61471 MB) w/2048KiB Cache, 

Re: the new VMt

[Andrey Savochkin]

Hello,

On Wed, Sep 27, 2000 at 01:55:52PM +0100, Hugh Dickins wrote:
> On Wed, 27 Sep 2000, Andrey Savochkin wrote:
> > 
> > It's a waste of resources to reserve memory+swap for the case that every
> > running process decides to modify libc code (and, thus, should receive its
> > private copy of the pages).   A real waste!
> 
> A real waste indeed, but a bad example: libc code is mapped read-only,
> so nobody would recommend reserving memory+swap for private mods to it.
> Of course, a process might choose to mprotect it writable at some time,
> that would be when to refuse if overcommitted.

Returning error from mprotect() call for private mappings?
It wouldn't be what people expect...

The other example where overcommit makes sense is fork() (not vfork) and
immediate exec in one of the threads.

Best regards
Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] 2.4 version of my duplicate IP and MAC detection patch

[Marc MERLIN]

On Sat, Sep 23, 2000 at 02:02:24PM +, Julian Anastasov wrote:
> > I didn't receive  any negative comments, except for Alexey  who believed the
> > check should be done in user space.
> 
>   Now you receive another negative comment, for the 2.2 version :)
 
Thanks for the feedback, it is appreciated.
 
>   Currently, in Linux 2.2 there is a device flag "hidden" which
> is based on this statement: many host can configure same IP address
> but it is assumed that only one is advertised. Your patch now will

Yes, I know LVS and arp_invisible, later renamed arp_hidden

> print messages for all these hidden addresses. They are not advertised
> and there is no problem caused from duplication.

I thought about that,  but isn't the shared IP just an IP  alias and not the
primary IP? As far as I know, the machines which share the IP have a primary
IP and put that one in their ARP packets, so my patch should not complain.

That said, adding a flag that lets you disable the duplicate IP detection on
an interface basis wouldn't be a bad idea, I'll look into this.

> - sip=127.0.0.0/8, this address is shared but we "assume" it is not
> advertised from the neighbours
 
Are you saying that  some machines would ARP with a  source IP of localhost?
That'd be  pretty broken, wouldn't  it? Or you talking  about a kind  of DOS
that would trigger warnings on all the machines?
(the dupe check could ignore that)
 
> - you work with ifa_address and not with ifa_local and ifa_mask.

I'll look into this too.

Thanks for your feedback.
Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger [EMAIL PROTECTED] for PGP key and other contact information
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-test9-pre7

[Chris Porter]

I am having problems with lockups on an SMP box running 2.4.0-test9-pre7 for 
weeks now. I am using it as a network monitoring machine and I am using the 
same software on a box running kernel 2.2.17 with no problems. The error I am 
receiveing on the 2.4.0-test9-pre7 box is as follows: 

Unable to handle kernel NULL pointer dereference.
NMI Watchdog detected lockup on CPU1.


The System I am using is : 

Dual Pentium III 800
Super Micro P6DGU
Slackware 7.1


Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Alexander Viro]

On Thu, 28 Sep 2000, Miles Lane wrote:

> Perhaps the Linux community should draft up some
> guidelines for the job of maintainer that would include
> some mechanism for replacing a maintainer who is not
> effectively shepherding his port.

Since when it is decided by community? It's not a democracy. You don't
like it - maintain your tree and accept/reject whatever you want.

I find plonk-by-domain silly, but the contents of filters is the private
business of person using them. Period. We've been through that quite a few
times when Alan-uses-*R*S threads appeared on the list. Enough, already.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Horst von Brand]

Timur Tabi <[EMAIL PROTECTED]> said:
> Horst von Brand <[EMAIL PROTECTED]> on Wed, 27 Sep 2000 16:50:12 -0400

> > I'd say it is important specifically in device drivers, and less so
> > elsewhere ;-)

> Yes, it's more important, but I've looked at the assembly code that my
> C++ compiler generates, and it's very clean.  In fact, when you're
> writing code that by design is OO, then using C++ tends to generate
> better code, not worse, since the language more closely matches the
> design.

Your compiler being? I for one wouldn't trust others, C++ is still very
much in flux in gcc...

> > A couple of points:
> > 
> > - The kernel is C, mixing in C++ for no *real* good reason is just making
> >   it harder to work on.

> True, but I'm not advocating doing it for no real reason.  I'm advocating
> using C++ for code that is OO by design.  My OS/2 device drivers are a
> mix of C and C++, wherever appropriate.

The kernel is OO in design, just not written in C++. And as I said before,
you either redesign Linux from the ground up for C++'s idea of OO, or use
wrappers and pay the cost in bloat and performance. Neither is acceptable...
maybe for a specific case, but not for general use.

> > - The work you do to match the kernel's object model to C++ is strictly
> >   wasted effort: The kernel's interfaces _do_ change, sometimes radically,
> >   and you'll have to keep up

> But that applies to C code as well.  In fact, the #2 gripe I hear about
> Linux development is how the API's change so often and without any regard
> to existing code that depends on it.  (#1 gripe: the dearth of good
> development tools).

Gripe #1 is complete nonsense (not _that_ thread again...), gripe #2 is
mostly nonsense (sure, Linux could still have the internal interfaces from
1.0, but the cost would be prohibitive for an OS that wants high
performance on machines that are at least an order of magnitude larger than
they were then).

And for whatever #2 is worth, you are only making it _harder_ for yourself
to track the changes by plastering something over the interface.

> > - The idea of reusing code from other OSes with a very different internal
> >   layout will only make the point above even worse

> Not always true.  Some drivers, like complex PCI audio drivers, are mostly
> OS-independent.  They get some data from the OS, and then spend 90% of their
> code just talking to the hardware.

> > - History shows that no kludged-on C++ code will show up in the standard
> >   kernel, so you loose the main advantage Linux gives you: Hundereds of
> >   other people that fix bugs and port forward for you

> True, if you want to write a driver that goes into the kernel, you need to
> conform to Linus' whims^H^H^H^H^Hstandards.  But considering how difficult it
> is to get a driver into the kernel anyway, it often doesn't make a
> difference.

I'd be a bit more careful. It is in large part those "completely
ridiculous, nobody will ever be able to write decent software that way"
whims that got Linux to where it stands today.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: hdb errors with 2.2.16

[Andre Hedrick]

If you launched out of Windows to install Linux, DON'T do that.
If you have booted into Linux from Windows, DON'T do that.

I can fix a lot of things that MS does to the ATA-Bridge/Chipset but I do
not like to go dorking int the PCI/ISA bridges to fix up issues.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Posting to this list without 500 bounces?

[Jeff V. Merkey]

Mike,

You can have a mail account on one of my servers for FREE and FOREVER. 
I would be happy to host an email account for you if you like.  What do
you want your account to be?  I will create an email account, and if you
want this, then tell me and I'll have our IS guy forward you a password.
:-)

Jeff

"Mike A. Harris" wrote:
> 
> This message may be seen by some to be OT, but it concerns
> replying to messages from this specific mailing list, so I'm
> asking it here.
> 
> My ISP's smtp is in ORBS and they don't seem to give a shit, and
> mails to this list get 50 bouncebacks because of it.  So, I set
> up my local MTA to send directly from home, instead of via the
> ISP's SMTP.  I figured despite the slowness, it would solve the
> problem.  Now I'm getting back all sorts of bounces from machines
> blocking using something at "www.mail-abuse.org/dul" which
> appears at a glance to be some list of all ISP's dialup modems or
> something - meaning using my dialup machine with my own MTA is
> going to be just as bad or worse..  SIGH.
> 
> Short of switching ISP's, is there some recommended way to get
> mail out to the list without getting blocked by drop dead spam
> filters?  Please feel free to throw me at another list that is
> more appropriate, or flame away, or whatever..  I'd just like to
> get this stupid MTA problem over with so I don't get 50 bounces
> due to ORBS blockers, etc..
> 
> For the record, even though it is killing me right now, I agree
> with the usage of ORBS and similar services for privacy and spam
> blocking.  Feel free to flame me for that too.  ;o)
> 
> Again, sorry if you feel this is OT, but I don't have this
> problem on other lists, and someone here likely has a good
> answer.
> 
> --
>  Mike A. Harris  -  Linux advocate  -  Open source advocate
>Copyright 2000 all rights reserved
>--
> If you're interested in computer security, and want to stay on top of the
> latest security exploits, and other information, visit:
> 
> http://www.securityfocus.com
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Mike Touloumtzis]

On Thu, Sep 28, 2000 at 02:30:00AM +0200, Igmar Palsenberg wrote:
> 
> > Again, you don't need to use exception handling in order to use C++.
> > None of my C++ drivers use exception handling, and they don't need
> > to.
>
> You implement C++, or you don't. I hate things only partially
> implemented / used, it's a pain in the ass.
>

(not that I'm defending C++ support in the kernel, but...)

"We'd need all of C++, or nothing" is a bogus argument.  It's perfectly
reasonable to want to use a subset of C++, since C++ is such an
all-inclusive language.  At my last systems programming job (at
Geoworks) we had a whole graphical embedded OS implemented in C++ and had
basically no bloat or performance problems (and it had one of the only
Java implementations I've seen that didn't suck performance-wise :-).
The problems we ran into were almost always related to crappy C++
support in embedded compilers; it was always nice when we got to use g++.

Of course, 2/3 of our coding conventions were made up of "don't use X
feature of C++", where some values of X were "templates" and "exceptions".
Even (especially) with that stuff removed, you get a reasonably
straightforward language for systems programming.  Of course, we also
shipped OS + apps as a single, statically linked image (appropriate for
a cell phone w/ no MMU), so we also didn't have to deal with the binary
compatibility problems that C++ frequently brings.

miket

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Module unresolved symbol on 2.4.0-test8 SMP

[Keith Owens]

On Wed, 27 Sep 2000 14:11:30 -0500 (CDT), 
[EMAIL PROTECTED] (Sam Watters) wrote:
>[root@porsche13 themod-dev]# insmod themod.o
>themod.o: unresolved symbol write_lock
>themod.o: unresolved symbol read_lock
> 
>gcc -Wall -Wstrict-prototypes -fomit-frame-pointer -pipe -march=i686
>-fno-strict-aliasing  -D__SMP__ -DMODULE -D__KERNEL__ -DLINUX -Dlinux 
>-DDEBUG -I../../../include -c themod.c 

Compile with -O2 otherwise functions will not be inlined.  The Linux
kernel requires -O2, it is not an option.  I'm surprised this is not in
the FAQ.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

hdb errors with 2.2.16

[Alexander Valys]

I just upgraded the motherboard and case on one of my boxen.  Win2k
installed fine, but when I went to install linux on the second HD, I got the
following errors while formatting it.
[writing inode tables] - slackware kernel:hdb:irq timeout:status=0xd0 {busy}
slackware kernel:ide0:reset:success
and later
writing superblocks, etc - slackware kernel:hdb:irq timeout:status=oxd0
{busy}
slackware kernel:ide0 reset timeout:status=0x80 {busy}
slackware kernel:hdb:status timeout:status=0x80 {busy}
slackware kernel:hdb:drive not ready for command
slackware kernel:ide0:reset:success

I have a Tyan Tiger 133 motherboard (dual capable, currently single).  It
uses the Via Pro133A chipset.
hda=20gb maxtor
hdb=15gb maxtor
I don't know much about kernel programming, although I have three years
experience with linux.  Any information about what this message means would
be very helpful.  I am using kernel 2.2.16.
   
 --A. Valys

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

PATCH: Fix to slab.c for SMP (test9-pre7)

[Juan J. Quintela]

Hi
In previous mails I reported that test9-preX (X>=3) freezes
when running in SMP mmap001.  I have found that the problem
was in how was handing the slab cache by cpu.  With this patch
mmap001 returns to work (i.e. it loops a lot in the VM layer,
but the same loops than in UP).

Linus, if you see no problems, please apply. (If you want the patch
without the shrink_[id]_caches part, please, let me know).

This patch does:

- shrink_[id]_caches return the count of the freed pages (from ingo
  and marcelo patch)
- removes the ret variable in smp_call_function (it was unused)
- removes the slab_cache_drain_mask/slab_drain_local_cache and its
  references for the timer interrupt code.  That calls are now done
  with smp_call_function, that lets us to simplify a lot the code (we
  don't need the cache_drain_wait queue anymore.
- Change the cache_drain_sem semaphore to cache_all_lock spinlock, as
  now we never sleep/schedule while holding it.  The name is changed
  because it is not only used by the drain routines it is also used by
  the update ones.
- slab_drain_local_cache is divided in the functions: 
slab_drain_local_cache
do_ccupdate_local
  as we known a compile time _which_ part of the function we want to
  call.
- pass the spinlock calls inside slab_cache_all_sync, as they are
  needed only when calling that function.  The wait queue is not
  needed anymore.  This function used global variables to pass
  arguments to slab_drain_local_cache, that has been changed to use
  global arguments.
- do_ccupdate & drain_cpu_caches code has been refunded inside
  slab_cache_all_sync, as the same code except for one line.

- In the process, the net result are ~40 less lines of code

Thanks to Phillip Rumpf, Stephen Tweedie, Alan Cox, Ingo & the rest of the
people that explained me the SMP/cross CPU mysteries.

Any comments, suggestions are welcome


Later, Juan.

diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/arch/i386/kernel/smp.c working/arch/i386/kernel/smp.c
--- base/arch/i386/kernel/smp.c Tue Sep 26 03:46:03 2000
+++ working/arch/i386/kernel/smp.c  Wed Sep 27 23:45:30 2000
@@ -464,7 +464,7 @@
  */
 {
struct call_data_struct data;
-   int ret, cpus = smp_num_cpus-1;
+   int cpus = smp_num_cpus-1;
 
if (!cpus)
return 0;
@@ -485,7 +485,6 @@
while (atomic_read() != cpus)
barrier();
 
-   ret = 0;
if (wait)
while (atomic_read() != cpus)
barrier();
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/dcache.c 
working/fs/dcache.c
--- base/fs/dcache.cTue Sep 26 03:34:00 2000
+++ working/fs/dcache.c Wed Sep 27 00:34:13 2000
@@ -572,14 +572,8 @@
if (priority)
count = dentry_stat.nr_unused / priority;
prune_dcache(count);
-   /* FIXME: kmem_cache_shrink here should tell us
-  the number of pages freed, and it should
-  work in a __GFP_DMA/__GFP_HIGHMEM behaviour
-  to free only the interesting pages in
-  function of the needs of the current allocation. */
-   kmem_cache_shrink(dentry_cache);
 
-   return 0;
+   return kmem_cache_shrink(dentry_cache);
 }
 
 #define NAME_ALLOC_LEN(len)((len+16) & ~15)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/inode.c 
working/fs/inode.c
--- base/fs/inode.c Tue Sep 26 03:34:00 2000
+++ working/fs/inode.c  Wed Sep 27 00:34:13 2000
@@ -471,14 +471,8 @@
if (priority)
count = inodes_stat.nr_unused / priority;
prune_icache(count);
-   /* FIXME: kmem_cache_shrink here should tell us
-  the number of pages freed, and it should
-  work in a __GFP_DMA/__GFP_HIGHMEM behaviour
-  to free only the interesting pages in
-  function of the needs of the current allocation. */
-   kmem_cache_shrink(inode_cachep);
 
-   return 0;
+   return kmem_cache_shrink(inode_cachep);
 }
 
 /*
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/include/linux/slab.h working/include/linux/slab.h
--- base/include/linux/slab.h   Wed Sep 27 00:16:36 2000
+++ working/include/linux/slab.hWed Sep 27 16:23:51 2000
@@ -76,14 +76,6 @@
 extern kmem_cache_t*fs_cachep;
 extern kmem_cache_t*sigact_cachep;
 
-#ifdef CONFIG_SMP
-extern unsigned long slab_cache_drain_mask;
-extern void slab_drain_local_cache(void);
-#else
-#define slab_cache_drain_mask 0
-#define slab_drain_local_cache()   do { } while (0)
-#endif
-
 #endif /* __KERNEL__ */
 
 #endif /* _LINUX_SLAB_H */
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/kernel/timer.c 
working/kernel/timer.c
--- base/kernel/timer.c Mon Aug 28 23:28:27 2000
+++ working/kernel/timer.c  Wed Sep 27 23:38:09 2000
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -596,9 +595,6 @@
  

Re: Russell King forks ARM Linux.

[Miles Lane]

Well, this sucks.

I am not sure how you both came to this impass, but it really is quite
unacceptable.  I think there are several problems here:

   No maintainer should cut off contribution from an entire
   company to a platform it intends to help support and
   implement.

   Usually these kinds of impasses are a result of limited thinking
   on the part of both parties.  You and the contributors within
   Compaq/DEC should extend an olive branch of some sort and
   try to focus on technical solutions that will work for everyone,
   including the maintainer.

It seems to me that if the conflict has been over architecture
for serial devices, you could simply agree to pursue different
paths for a while and see how that pans out.  I know of several
places in the Linus kernel where this is being done -- the
HCDs in the new USB support and the experimental VMs.
Specifically, there are two UHCI HCDs:  usb-uhci and uhci.
They were written by different people and share no code.
They should both, however, be completely compatible with
one another, since they are endeavoring to support the same
specification.  This has been blessed by Randy Dunlap for the
time being.  I believe there will come a time when one of the
UHCI HCDs will be dropped, but in the meantime, both provide
good exprimental feedback.  Perhaps you and Russell could
agree on such a path.

The bottom line is that I think you should be looking at your
contributions with a long view and think creatively about
how to avoid conflict with Russell.  On the other hand, I'm
not sure what the process is regarding the selection of
a maintainer, but it seems to me that remaining open to
contribution is a requirement for a maintainer. 

Perhaps the Linux community should draft up some
guidelines for the job of maintainer that would include
some mechanism for replacing a maintainer who is not
effectively shepherding his port.

   Miles

George France wrote:

> Greetings;
> 
> As you probably know Russell King is the maintainer of ARM Linux.  Him and I
> have been debating how serial ports should be handled on an off for months
> now. IMHO, today he lost it, declaring that he was going to block all
> e-mails from Compaq, which means he can not recieve any more ARM Linux
> patches from us.  I have tried every method that I know of, to work with
> him, but he has cut off all commutations. So starting tomorrow, we will be
> submitting patches directly to the kernel mailing list, since Russell will
> not even receive our e-mails. I will also be setting up an ARM mailing list
> and web pages, for those that wish to participate. It is too bad that
> Russell has decided to create a fork in the ARM Linux tree. It is his
> choice.
> 
> Attached is his e-mail for the curious.
> 
> Best Regards,
> 
> 
> --George
> 
> George France,  [EMAIL PROTECTED]
> Cambridge Research Laboratory, Compaq Computer Corporation
> One CambridgecenterMS: CRL
> Cambridge, MA 02142 USA
> 
> 
> 
>> Since this issue raises your blood pressure to an explosive level, I will
>> not bother you again. I can handle this without you.
> 
> And thus you shall.  I shall not be accepting anything further from you.
> Call this what you will, but you have brought this on yourself and your
> organisation.  I am NOT going to work with incompetent selfish people who
> refuse to listen to reason.
> 
> Good luck, we'll benefit without your uninformed arguments.
> 
> From this point on, I shall be blocking you and your companies email
> addresses.
> I don't want to hear from you ever again.  You're not worth the bandwidth
> you
> waste.
> 
> Appologies in advance to anyone at the old crl.dec.com domain who can listen
> to reason, I've had enough of this shit.
>_
>   |_| - ---+---+-
>   |   |Russell King   [EMAIL PROTECTED]  --- ---
>   | | | |http://www.arm.linux.org.uk//  /  |
>   | +-+-+ --- -+-
>   /   |   THE developer of ARM Linux  |+| /|\
>  /  | | | ---  |
> +-+-+ -  /\\\  |
> 
> ___
> http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Andre Hedrick]

> Well, people said the same thing to me when I started writing OS/2 drivers in
> C++.  Nowadays, it's very common for non-*nix operating systems, especially
> Windows.

> This design is inherently object-oriented.  The old C code for audio drivers
> was horribly convoluted.  When I rewrote it in C++, there was less code, it was
> easier to maintain, and ther resulting binary was actually smaller and faster!
> And that's all because the language fit the design better.

Thats nice, but the King Pengiun says NO and until he says yes and
everyone can agree on a C++ Style/Rules/Public/Private list that does not
force duplication of everything and every layer ... well you get the
point.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

test9-pre7 lockup

[Adam Huffman]

This has happened three times now, when dd'ing a boot image to a floppy.
The screen goes blank, Alt+SysRq don't seem to have any effect.

System:

Athlon 800
KA7-100

RedHat 7.0

The first time there was a data CRC error listed in /var/log/messages,
so I tried with a different floppy, but the same thing happened, this
time with no syslog output.

Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Andre Hedrick]

On 27 Sep 2000, Christoph Hellwig wrote:

> Abel Mu?oz Alcaraz <[EMAIL PROTECTED]> wrote:
> > Hi everybody,
> 
> > I want to develop a linux kernel module in C++ but I don't find makefiles
> > and/or sorce files examples to do this.
> 
> Don't do that.
> Search the list-archive for C++ and read why.

Oh let him find out the hard way as every other C++ junkie has.
Go write your code, get it rejected with out a reason and then go rewrite
it in straight C.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Alexander Viro]

On Thu, 28 Sep 2000, Daniel Phillips wrote:

> Timur Tabi wrote:
> > The real advantage comes when you're writing a driver where the design is
> > inherently object-oriented.  I can't give an example in Linux...
> 
> The VFS is inherently object-oriented.  Each filesystem works by
> overriding a few methods stored in function table structs.  The MM is
> well on its way to being object-oriented - check out 'struct
> address_space'.

Check also vm_area_struct - that's what memory contexts consist of
(user memory consists of objects that correspond to areas; pagein,
pageout, etc. are methods of these objects; mmap() and friends
create/manipulate/destroy them). File mappings (both shared and
private) are derived classes, ditto for attached shm segment, etc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Stephen Williams]

[EMAIL PROTECTED] said:
>    

Oops, typo!

 

- -- 
Steve Williams"The woods are lovely, dark and deep.
[EMAIL PROTECTED]  But I have promises to keep,
[EMAIL PROTECTED]and lines to code before I sleep,
http://www.picturel.com   And lines to code before I sleep."



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Socket Interface

[Chen, Eric]

Dear Helpers:

This is a question from a Linux idiot.  Please bear with me.  I have brought
up a PC running Linux 6.2.  I need to develop a simple C program using
TCP/IP protocol (socket interface) to talk to another PC on the network.  I
need some help in getting the necessary documentation and sample code about
socket interface to write such program.  Any input will be appreciated.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Alexander Viro]

On Thu, 28 Sep 2000, Igmar Palsenberg wrote:

> OO is indeed != C++. But since it's a relative if C, it's the most
> suitable option to use in the kernel. 

What's wrong with C itself?

> >  - A _lot_ of the kernel code/design is inherently object-oriented. So
> >pardon our collective scepticism when YAC++Advocate comes along waving
> >the "OO ergo C++" underw^Wflag
> 
> OO design had nothing to do with OO implementation. I can design a system
> totally in OO, and implement it in C. Really stupid thing to do I think,
> but it's possible..

Try it someday. That's how VFS/VM/filesystems are done.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: A brief thought on 'external' patches and forks...

[Christopher W. Curtis]

Alexander Viro wrote:
> 
> On Wed, 27 Sep 2000, Christopher W. Curtis wrote:
> 
> > Not subscribed, so please Cc: if you reply...
> >
> > I'm just jumping in on what is probably a huge overblown thread full of
> > "make it a config option" suggestions, but regarding the BigIron (NUMA)
> > () patches ...
> 
> ??? 
> What thread? All I see is a single reference to, excuse me, Slashdot.
> Which is equivalent to "National Enquirer says that..." No offense, but
> assumption that tabloids bear any relation to reality is quite, erm, odd.

Sorry ... I read it at ZDNet after seeing it at Linux Today, then saw it
at Slashdot.  Figured I couldn't be the only one who spouted off an
uninformed email to the list, but perhaps I am the only other person in
the world ignorant enough to do so.  =)

Christopher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Stephen Williams]

> - C++ gives overhead. With something like a kernel that's unwanted. 

I don't want to take a position on the matter of C vs. C++ in the Linux
kernel. However, I *have* done some realistic work to show that C++ does
not inherently introduce bloat. (I do my embedded work in C++.)



Of course, I write my Linux drivers (and GIMP plug-ins) in C, not C++, and
that's fine, too. I'm just glad it's not Scheme:-)

-- 
Steve Williams"The woods are lovely, dark and deep.
[EMAIL PROTECTED]  But I have promises to keep,
[EMAIL PROTECTED]and lines to code before I sleep,
http://www.picturel.com   And lines to code before I sleep."


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: spontaneous reboots 2.4.0-test9-ore7

[Michael Meding]

Hi there,

I forgot to mention that I either get reboots or lockups when I put
little stress on the machine (like compiling dri code and wine and open
a lot of netscapes).

Greetings

Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Igmar Palsenberg]

> > - C++ gives overhead. With something like a kernel that's unwanted. 
> 
> C++ gives an overhead only if you abuse it.  The C++ code in my drivers does
> nothing that the equivalent C doesn't also do, except that it's easier to read.

It gives overhead. At least, a year ago with gcc.

> 
> > - Things like exception handling is hard to do in a kernel. 
> 
> Again, you don't need to use exception handling in order to use C++.  None of
> my C++ drivers use exception handling, and they don't need to.

You implement C++, or you don't. I hate things only partially implemented
/ used, it's a pain in the ass.

> > - The're a lot more people that know C than C++
> 
> True, but all the driver programmers I know personally already know C++.

C++ is a total different aproach of working things out. I think that will
collide with the way of thinking that is 'in' the current kernel right
now.


Igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: A brief thought on 'external' patches and forks...

[Alexander Viro]

On Wed, 27 Sep 2000, Christopher W. Curtis wrote:

> Hi,
> 
> Not subscribed, so please Cc: if you reply...
> 
> I'm just jumping in on what is probably a huge overblown thread full of
> "make it a config option" suggestions, but regarding the BigIron (NUMA)
> () patches ...

??? 
What thread? All I see is a single reference to, excuse me, Slashdot. 
Which is equivalent to "National Enquirer says that..." No offense, but
assumption that tabloids bear any relation to reality is quite, erm, odd.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PATCH 2.4.0.9.7: clean up toshiba SMM driverg

[Alan Cox]

> Hum nobody has said anything to me till now. I was holding back with my
> patch till I had time to test it on more that one laptop. While the

Umm my mail obvious blackholed somewhere - sorry about that

> patch looks Ok, passed experience has shown it must be verified on more
> than one model of Toshiba laptop before being marked as safe. Ideally a
> dozen or so laptop models is best.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Anton Altaparmakov]

At 22:14 27/09/2000, Timur Tabi wrote:
>** Reply to message from Alan Cox <[EMAIL PROTECTED]> on Wed, 27 Sep
>2000 22:00:54 +0100 (BST)
>
> > > I have written the Windows platform version in C++ using Numega's tools
> > > encapsulating the driver code in classes.
> > > More of this classes isn't OS specific and it work well in any OS.
> >
> > And do you rely on any exception throwing ?
> >
> > If you use no exceptions (including thus using new and other 
> constructors that
> > allocate) you should be ok.
>
>I don't think any OS supports exception handling in a driver.  It wouldn't 
>make
>much sense, since there's no way for a driver to really "exit" (which is the
>ultimate destination of the exception).

Maybe we have different definitions of "exception" and possibly different 
definitions of what can be considered an "OS" but Windows NT drivers use 
exceptions(+handlers) all over the place. - The code is full of RtlUnwind 
calls as well modifications to exception handler lists (usually addition of 
handler on function entry and removal on function exit).

Just my 2p.

Anton

P.S. I am not saying that exceptions are good or bad, just that they exist 
in Windows, whether you consider it an OS or not...

P.P.S. Flames to /dev/null...

-- 
  "Education is what remains after one has forgotten everything he 
learned in school." - Albert Einstein
-- 
Anton Altaparmakov  Voice: 01223-333541(lab) / 07712-632205(mobile)
Christ's CollegeeMail: [EMAIL PROTECTED]
Cambridge CB2 3BUICQ: 8561279
United Kingdom   WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Alexander Viro]

On Thu, 28 Sep 2000, Igmar Palsenberg wrote:

> Some arguments why not to use it in the kernel :
> 
> - C++ gives overhead. With something like a kernel that's unwanted. 
> - Things like exception handling is hard to do in a kernel. 
> - The're a lot more people that know C than C++
> 
> And I probably forgot a few :)

Yep.
 - OO != C++. It's a style of programming and while you can do OO in C++
   you can easily do it in other languages (or do non-OO in C++, indeed)
 - A _lot_ of the kernel code/design is inherently object-oriented. So
   pardon our collective scepticism when YAC++Advocate comes along waving
   the "OO ergo C++" underw^Wflag

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PATCH 2.4.0.9.7: clean up toshiba SMM driver

[Jonathan Buzzard]

[EMAIL PROTECTED] said:
> This driver was merged from 2.2.x and needs some more cleanups.  Horst
> von Brand posted a patch on lkml against this driver, too, but his
> cleanups had a bug in it, and weren't as terse with procfs as the
> following patch is... 

Hum nobody has said anything to me till now. I was holding back with my
patch till I had time to test it on more that one laptop. While the
patch looks Ok, passed experience has shown it must be verified on more
than one model of Toshiba laptop before being marked as safe. Ideally a
dozen or so laptop models is best.

Remember any error in this driver could render a Toshiba laptop quite
literally unusable. With a trip to a Toshiba authorized reseller, the
parting of some cash, and with potential data loss.

> Against 2.4.0-test9-pre7, and tested on my laptop.. 

Which may not be enough. When I submit my own version of the driver
is it permissible to have a sprinkling of #ifdef's so it still compiles
on older kernels. I would prefer to only have to maintain one version.

JAB.

-- 
Jonathan A. Buzzard Email: [EMAIL PROTECTED]
Northumberland, United Kingdom.   Tel: +44(0)1661-832195


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

A brief thought on 'external' patches and forks...

[Christopher W. Curtis]

Hi,

Not subscribed, so please Cc: if you reply...

I'm just jumping in on what is probably a huge overblown thread full of
"make it a config option" suggestions, but regarding the BigIron (NUMA)
() patches ...

Would it be possible to distribute along with the kernel a directory
'unsupported/', or 'patches/', or what have you, then from within the
Makefile (make *config) prompt the user:

Apply unsupported patches (EXPERIMENTAL) [y/N]?

Then, if the user answers 'y', it can simply look for 'filename.patch'
and 'filename.desc'.  .patch would of course be the diff, .desc would be
a simple description like:

-
Support Big Hardware (SGI NUMA)

This patch enables NUMA (Non-Uniform .
-

patch should be run twice for each diff - "patch --dry-run" to see if
there would be a conflict, then the real patch.  The man page doesn't
mention return values, but I assume it returns non-zero on error.

This might also make it easier (?) to keep locally modified kernels
up-to-date with updated kernels.  Even if it doesn't, it shouldn't make
it any more difficult.  The primary use for this would probably be
testing for things like Alan Cox or Andreas' patches, but it also seems
like a reasonable thing to do in light of the massive changes and
forking potential of certain commercial patches.

Please note I don't want to debate the merits of forking - I think this
may help prevent it, whether that is good or bad is irrelevant.  The
most important thing, imo, is that this requires no changes to the
kernel itself - just some changes to the Makefile and config scripts. 
It can also be downloaded seperately as a
"linux-patches-x.y.z-n.tar.bz2" file so as not to bloat the kernel.

(Hmm, then I suppose you could "make patches" and it would wget the most
recent version for your kernel from kernel.org ... anyway)

regards,
Christopher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Timur Tabi]

** Reply to message from Igmar Palsenberg <[EMAIL PROTECTED]> on Thu, 28 Sep
2000 01:45:40 +0200 (CEST)


> - C++ gives overhead. With something like a kernel that's unwanted. 

C++ gives an overhead only if you abuse it.  The C++ code in my drivers does
nothing that the equivalent C doesn't also do, except that it's easier to read.

> - Things like exception handling is hard to do in a kernel. 

Again, you don't need to use exception handling in order to use C++.  None of
my C++ drivers use exception handling, and they don't need to.

> - The're a lot more people that know C than C++

True, but all the driver programmers I know personally already know C++.




-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Q: network drivers interface changes

[Ivan Passos]

On Wed, 27 Sep 2000, Hen, Shmulik wrote:
> 
> Is there a good source of information that describes the changes in network
> driver interface between 2.2.x and 2.4.x kernels ?

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0002.1/0408.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0002.1/0461.html

Hope this helps. :)

Regards,
Ivan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Erik Mouw]

Russell King writes:
> George France writes:

[snip]

OK, so the flamewar landed over here. I have taken the role as flame
fighter and I have written a summary which you can read at:

  http://www-ict.its.tudelft.nl/~erik/flamewar.txt

We are currently trying to solve this issue privately, so the last
thing we can use is another flamewar on this list. Please help me
to solve this issue by not putting more fuel on this fire.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Mike Touloumtzis]

On Wed, Sep 27, 2000 at 04:14:39PM -0500, Timur Tabi wrote:
> 
> I don't think any OS supports exception handling in a driver. It
> wouldn't make much sense, since there's no way for a driver to really
> "exit" (which is the ultimate destination of the exception).
>
> By the way, new and delete are NOT exceptions. They are simply
> wrappers for malloc() and free(). Just define your own malloc and free
> (they can be wrappers for a kernel memory allocation API, or you can
> write your own heap manager), and new and delete work just fine.

new and delete used to be just constructor/destructor-calling wrappers,
before exception handling went into the language.  Now new is supposed
to throw a bad_alloc exception instead of returning NULL.  If you have
an operator new like this:

   void *operator new(size_t) { return NULL; }

then g++ will complain about it even with '-fno-exceptions'.  You can use
new and delete in code without exception handling, I'm just explaining
why people would expect it to be an issue.

Periodically someone posts a minimal C++ runtime to LKML.  A much larger
problem than the runtime is the fact that C++ is not the language of
choice of other kernel developers, making them reluctant to deal with
(and hence, to incorporate) your driver.

miket

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Russell King forks ARM Linux.u

[Igmar Palsenberg]

> Yes you should be able to mix 16x50 chips with sa1100 chips. That is not the
> issue. I believe that people can place any mixture of IC's on a PCB. 

Letting it make sense is another issue. Placing a Z80 next to an AMD
Irongate doesn't make sense to me...

> > HPA can I suggest the description for major 4 minor 64+ is 
> > amended to be clear
> > that its the 16x50 driver.
> 
> That may help others but it is still not the issue.
> 
> > 
> > The proper way to manage ramdisks like that is to open each 
> > possible set of
> > ports and find which one fits your need - or of course you 
> > can use devfs which
> > for an embedded setup with flash based root may in fact be a 
> > very attractive
> > solution for other reasons too
> >
> 
> We have thought of the above solutions and I believe that Erik Mouw has a
> one line fix that will make everybody happy about the serial port. IMHO, the
> current problem is that Russell gets too angry to talk about this issue. I
> believe that no problem can be solved with a flame war going on. That is why
> I decide to stop speaking with him about the serial port issue. He then
> decided to block the e-mails. So here we are.
> Best Regards,
> 
> 
> --George


Igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Igmar Palsenberg]

> Well, people said the same thing to me when I started writing OS/2 drivers in
> C++.  Nowadays, it's very common for non-*nix operating systems, especially
> Windows.

You call windows an OS ?? I call it a bunch of function calls with way to
many arguments written by a bunch of * that like to nag people instead
of making an OS stable.

> The real advantage comes when you're writing a driver where the design is
> inherently object-oriented.  I can't give an example in Linux, because I've
> only been writing Linux drivers for 6 months, but in OS/2, there are tons of
> places where a little OO lovin' goes a long way.  My initial use was in
> multimedia drivers.  In OS/2, the adio drivers need to keep track of multiple
> "streams" of audio data.  OS/2's advanced multimedia subsystem lets multiple
> applications open audio streams simultaneously, and the driver has to keep
> track of them.  If it has the hardware, it can play the streams simultaneously.
>  Otherwise, it has to manage stopping one stream to play the other.

Agree, OO could make life easier.

Some arguments why not to use it in the kernel :

- C++ gives overhead. With something like a kernel that's unwanted. 
- Things like exception handling is hard to do in a kernel. 
- The're a lot more people that know C than C++

And I probably forgot a few :)

> I've oversimplified it, but that's the general idea.
> 
> This design is inherently object-oriented.  The old C code for audio drivers
> was horribly convoluted.  When I rewrote it in C++, there was less code, it was
> easier to maintain, and ther resulting binary was actually smaller and faster!
> And that's all because the language fit the design better.




Igmar




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Daniel Phillips]

Timur Tabi wrote:
> The real advantage comes when you're writing a driver where the design is
> inherently object-oriented.  I can't give an example in Linux...

The VFS is inherently object-oriented.  Each filesystem works by
overriding a few methods stored in function table structs.  The MM is
well on its way to being object-oriented - check out 'struct
address_space'.  I haven't gotten into it much yet but I gather the
various buses are also organized in much the same way.  On the whole,
Linux is very object-oriented, but it's not C++-oriented.  The bad news
is you don't get any class syntax support from the compiler, you have to
write it all out by hand; the good news is that you tend to be well
aware of exactly what code is being executed to do a given job.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-t9p7 and mmap002 - freeze

[Roger Larsson]

Hi,

Tried latest patch with the same result - freeze...

No extra patches added.

running from console as root
mmap002 from memtest-0.0.3
with RAMSIZE defined as 90 MB (I have 96MB)
after a while with heavy disk access (thrashing?) the drive
becomes silent - no more progress...
[if you can not repeat this - try with less memory 32 MB...]

Magic works!

Magic memory
 Constantly LOW on inactive_clean (0 is the most common)
 lots of shared memory (almost equals active)
 [can be normal condition since mmap002 produces dirty
  mmaped pages]

Magic process:
  Manual samples gave the following locations.
  (NOTE: not a call trace)
  We are trying to clean pages, but do we make any
  progress since disk is silent?

Trace; c0127d85 
Trace; c0126dad 
Trace; c0127e00 
Trace; c0128035 
Trace; c0127dcc 
Trace; c0127dd0 
Trace; c0127e00 
Trace; c012fd38 

Magic Sigterm (Alt+SysRq+E)
 Gives you a running system again.


Notes:
 Probably timing critical for entry into this state
 since adding a few printk:s makes it happen less often.
 I have even got complete mmap002 runs succeed - but
 disk is running too much and for too long time...
 a lot more than 10 min - normal run on previous testX
 did usually take less than 3 minutes.

/RogerL

--
Home page:
  http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: spontaneous reboots 2.4.0-test9-ore7

[Alan Cox]

> System is a AMD duron which is overclocked to (600) 800. However this
> system was running fine the last days throughout with earlier test9
> kernels. So I guess this is not the reason.

Who knows. You are running an unreliable, unpredictable set up - that really
makes the data useless. It could be relevant. If you can drop back to 600
and reproduce it that would be good

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

spontaneous reboots 2.4.0-test9-ore7

[Michael Meding]

Hi all,

my system keeps rebooting without motivation. During the reboots XF4.01
was running and a compile job in the backround.

System is a AMD duron which is overclocked to (600) 800. However this
system was running fine the last days throughout with earlier test9
kernels. So I guess this is not the reason.

System was rebooting no matter if kernel was compiled for i386 or
Athlon.

Please see attached information.

Greetings

Michael

PS: At least it is not eating my filesystem like in those ancient 2.3.xx
days.

Linux version 2.4.0-test9 (root@HAL) (gcc version 2.95.2 19991024 (release)) #3 Mit 
Sep 27 23:38:29 CEST 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 0001 @  (reserved)
 BIOS-e820: 07f0 @ 0010 (usable)
On node 0 totalpages: 32768
zone(0): 4096 pages.
zone(1): 28672 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=linux ro root=805 agp_try_unsupported=1
Initializing CPU#0
Detected 800.039 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1595.80 BogoMIPS
Memory: 126084k/131072k available (1778k kernel code, 4600k reserved, 137k data, 216k 
init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
CPU: L1 I Cache: 64K  L1 D Cache: 64K (64 bytes/line)
CPU: L2 Cache: 64K
CPU: AMD Duron(tm) Processor stepping 00
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xfb250, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
Initializing RT netlink socket
Starting kswapd v1.8
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq= dma=
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_daisy: aa5500ff(00)
parport0: assign_addrs: aa5500ff(00)
parport0: No more nibble data (0 bytes)
parport0: cpp_daisy: aa5500ff(00)
parport0: assign_addrs: aa5500ff(00)
parport0: Legacy device
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
i2c-core.o: i2c core module
i2c-dev.o: i2c /dev entries driver module
i2c-core.o: driver i2c-dev dummy driver registered.
pty: 256 Unix98 ptys configured
lp0: using parport0 (interrupt-driven).
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: neither IDE port enabled (BIOS)
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Loading I2O Core - (c) Copyright 1999 Red Hat Software
Linux I2O PCI support (c) 1999 Red Hat Software.
i2o: Checking for PCI I2O controllers...
I2O configuration manager v 0.04.
  (C) Copyright 1999 Red Hat Software
I2O Block Storage OSM v0.9
   (c) Copyright 1999, 2000 Red Hat Software.
I2O LAN OSM (C) 1999 University of Helsinki.
Serial driver version 5.02 (2000-08-09) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI 
ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10c
8139too Fast Ethernet driver 0.9.10 loaded
eth0: RealTek RTL8139 Fast Ethernet at 0xc880, 00:e0:7d:72:d3:80, IRQ 11
eth0:  Identified 8139 chip type 'RTL-8139A'
atp.c:v1.09 8/9/2000 Donald Becker <[EMAIL PROTECTED]>
  http://www.scyld.com/network/atp.html
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 96M
agpgart: Detected Via Apollo Pro KT133 chipset
agpgart: AGP aperture is 64M @ 0xd000
(scsi0)  found at PCI 0/14/0
(scsi0) Wide Channel, SCSI ID=7, 16/255 SCBs
(scsi0) Downloading sequencer code... 422 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
   
(scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8.
  Vendor: IBM   Model: DDRS-39130D   Rev: DC1B
  Type:   Direct-Access 

Re: Russell King forks ARM Linux.u

[Mike Touloumtzis]

On Wed, Sep 27, 2000 at 06:03:30PM -0400, George France wrote:
> 
> Please also read Mike Touloumtzis [[EMAIL PROTECTED]] posting in the
> arm-linux-kernel archives. He gets the concept. 

Maybe I do, but I thought I was agreeing with Russell :-).  Which
only serves to underscore the silliness of getting so heated about
it.

miket

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Mark Hahn]

> him, but he has cut off all commutations. So starting tomorrow, we will be
> submitting patches directly to the kernel mailing list, since Russell will

uh, this will be unpleasantly familiar to anyone who
was reading the linux-usb mailing list in Dec 99,
when George said, roughly "you are all so full of shit
that you're not worth working with, so on Monday we will begin 
designing our own USB for Linux".

Linux USB has survived quite nicely in spite of this,
which bodes quite well for ARM-linux ;)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Mike Touloumtzis]

On Wed, Sep 27, 2000 at 02:30:13PM -0700, H. Peter Anvin wrote:
> 
> For what it's worth, the SA1100 serial driver has been registered with
> me on the Low-Density Serial Ports major (204) as /dev/ttySA0-2 (minor
> 5-7).
> 
> Russ is 100% correct that different drivers shouldn't use the
> same device numbers, unless they are:
> 
> a) mutually exclusive,
> b) interface compatible, *AND*
> c) handle all arbitration necessary.
> 
> If (a), (b) and (c) are all satisfied, it is often justified to share
> device numbers and device nodes.

I jumped into this discussion on linux-arm-kernel before realizing
it had wandered here.

I don't see the major 204 allocation in devices.txt, so I'm not sure if
this has already been covered, but it would be nice to have an allocation
for "on-chip UARTs" in system-on-chip type configurations.  I recently
worked on a port to the Cirrus Logic EP7211, which is an ARM-based
system-on-chip (CPU, UARTs, LCD controller, DRAM controller, etc.)
It seems hoggish to ask for an allocation for such a non-general-purpose
piece of hardware.

If we had (say) 4 or 8 on-chip UART device numbers for regular serial,
plus a corresponding 4 or 8 for serial IR using the same UARTs, that
would cover things nicely (EP7211 has only 2 UARTs but I figure it'll be
good to leave some room).  And on-chip UARTs are by definition mutually
exclusive (unless you start talking about sharing /dev via NFS between
heterogeneous embedded systems).

miket

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Daniel Phillips]

Timur Tabi wrote:
> 
> ** Reply to message from Alan Cox <[EMAIL PROTECTED]> on Wed, 27 Sep
> 2000 22:00:54 +0100 (BST)
> 
> > > I have written the Windows platform version in C++ using Numega's tools
> > > encapsulating the driver code in classes.
> > > More of this classes isn't OS specific and it work well in any OS.
> >
> > And do you rely on any exception throwing ?
> >
> > If you use no exceptions (including thus using new and other constructors that
> > allocate) you should be ok.
> 
> I don't think any OS supports exception handling in a driver.  It wouldn't make
> much sense, since there's no way for a driver to really "exit" (which is the
> ultimate destination of the exception).

Ah, no, the ultimate destination of the exception is an exception
handler.  Thowing exceptions in drivers would be a wonderful thing to be
able to do, then maybe I wouldn't have to do a hard reset every time my
developmental filesystem oopes during mount.  Throwing exceptions has to
be coupled with code that can remember resource allocations and clean
them up along the path of the exception.  You have to have some support
in the task management too: if you want your throw to be efficient you
pretty well have to remember the trapping context in a static per-thread
location.  It's doable, I know, I've done it and the result tends to be
really nice to look at and easy to understand.  The code is usually
smaller and more efficient too because it isn't littered with a lot of
conditionals that just watch for errors and pass them back to the
caller.  You can use a cleaner function interface in many cases,
eliminating parameters here and there.

That said, do not expect to see exception handling in Linux any time
soon - the existing mechanisms may not be elegant but they work. 
Anybody who wants exceptions in the kernel will have to overcome a *lot*
of skepticism and there is exactly one way to do that: by showing code
that works and is better.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Igmar Palsenberg]

> Hi everybody,
> 
>   I want to develop a linux kernel module in C++ but I don't find makefiles
> and/or sorce files examples to do this.
>   When I compile the module, the gcc shows a lot of warnings.
>   I have tried to use 'extern "C" {}' in my source files, but the result is
> the same one.
> 
>   For example:
>   extern "C" {
>   #include 
>   }
> 
>   Can you help me?

C++ code is a no go. Kernel is in plain C, not C++. To many issues to deal
with, exception being one of them.



Igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.u

[Cort Dougan]

} The only thing I'm not sure is that I believe the SPARC people uses
} ttyS* for Zilog 8530-based serial ports.  I don't know if we want to
} define this as NS8250-family serial ports in light of that; I more
} tended to think of it as the "default" serial port for the
} architecture.
} 
} It's mostly up to the SPARC people, I guess...

We do the same with the PPC 8(x)xx chips.  We have an emulation layer that
gives us a 16550-like uart, though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Philipp Rumpf]

On Wed, Sep 27, 2000 at 02:30:13PM -0700, H. Peter Anvin wrote:
> Russ is 100% correct that different drivers shouldn't use the
> same device numbers, unless they are:
> 
> a) mutually exclusive,
> b) interface compatible, *AND*
> c) handle all arbitration necessary.

This doesn't handle the watchdog driver case, but that's special anyway.
(All watchdog drivers use the same device number, which has the nice effect
of not loading the softdog driver when you have a real hardware watchdog and
a driver for it).

> If (a), (b) and (c) are all satisfied, it is often justified to share
> device numbers and device nodes.

Could this go into the next revision of Documentation/devices.txt ?  There
certainly doesn't seem to be a good place to point people to right now.

Philipp Rumpf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Russell King forks ARM Linux.u

[George France]

Alan, excuse me, would you like to rephase that?? I already told Russell I
agreed with him that nothing could be done, at this late date. Read the
archives.

I quote myself. "I will agree with you that there is probably nothing that
can be done this
close to the release of 2.4.0"

Please also read Mike Touloumtzis [[EMAIL PROTECTED]] posting in the
arm-linux-kernel archives. He gets the concept. 


--George

> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 27, 2000 5:58 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
> [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: Russell King forks ARM Linux.u
> 
> 
> > So now we will have to send our patches to the kernel 
> mailing list, setup
> > out own mailing list and web pages.  It is not a problem 
> since we already
> > have a web site setup.
> 
> Personally I'd rather you accepted that everyone else agrees 
> with Russell about
> the major/minor issue and that -both- of you then stopped 
> behaving like five
> year olds. Everyone does stupid things now and again and if 
> you could both
> go back to being sane life would be far simpler
> 
> Alan
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.u

[Alan Cox]

> So now we will have to send our patches to the kernel mailing list, setup
> out own mailing list and web pages.  It is not a problem since we already
> have a web site setup.

Personally I'd rather you accepted that everyone else agrees with Russell about
the major/minor issue and that -both- of you then stopped behaving like five
year olds. Everyone does stupid things now and again and if you could both
go back to being sane life would be far simpler

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.u

[Alan Cox]

> The only thing I'm not sure is that I believe the SPARC people uses
> ttyS* for Zilog 8530-based serial ports.  I don't know if we want to
> define this as NS8250-family serial ports in light of that; I more
> tended to think of it as the "default" serial port for the
> architecture.
> 
> It's mostly up to the SPARC people, I guess...

What happens when you plug a PCI 16x50 card into a PCI bus sparc nowdays ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Russell King forks ARM Linux.u

[George France]

> > believe that no problem can be solved with a flame war 
> going on. That is why
> > I decide to stop speaking with him about the serial port 
> issue. He then
> > decided to block the e-mails. So here we are.
> 
> Well if you arent speaking to him, then it doesnt matter if 
> he blocks your
> emails..

I told him that I would stop speaking to him in regard to this issue. It
just makes it impossible to send him a kernel patch. What I find really
interesting is that he did not just block me but the entire domain.

So now we will have to send our patches to the kernel mailing list, setup
out own mailing list and web pages.  It is not a problem since we already
have a web site setup.

--George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.u

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> I can see where his confusion arises, but yes you are right, people need to be
> able to mix the 16x50 driver with the sa1100 driver. The ppc people went through
> fixing this. 
> 
> HPA can I suggest the description for major 4 minor 64+ is amended to be clear
> that its the 16x50 driver.
> 

The only thing I'm not sure is that I believe the SPARC people uses
ttyS* for Zilog 8530-based serial ports.  I don't know if we want to
define this as NS8250-family serial ports in light of that; I more
tended to think of it as the "default" serial port for the
architecture.

It's mostly up to the SPARC people, I guess...

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [Demo program]: Poor elevator performance in 2.4.0-test9pre6

[Matthew Fredrickson]

On Wed, Sep 27, 2000 at 04:10:38PM +1000, Robert Cohen wrote:
> 
> [EMAIL PROTECTED] wrote
> 
> I doubt this has any relevance whatsoever, but when I try this on a
> 2.2.16
> kernel running on top of a Pentium Pro 200 w/96megs of mem w/ a SCSI 2
> disk, I get some funny numbers:
> 
> matt@zeus:~/cwork/personal$ ./elv_test 8 30
> files created, 240 megs written at 4.32 megs/sec
> finished writing 240 megs written at 1794.23 megs per sec
> finished reading, 240 megs read at 1675.813817 megs/sec
> 
> Any ideas why I would be getting these numbers?
> -
> 
> That will teach me to play fast and loose with checking error returns
> from system calls. I wasnt specifying a mode when creating the files.
> So they were being created without user write permission..
> I dont know why it worked under 2.4.0. Maybe a kernel bug :-).
> 
> Anyway, a new version is available now at
> http://tltsu.anu.edu.au/~robert/elv_test.c

Ah, thanks.  I have much more likely results now:
matt@zeus:~/cwork/personal$ ./elv_test2 8 30
files created, 240 megs written at 3.91 megs/sec
finished writing 240 megs written at 2.28 megs per sec
finished reading, 240 megs read at 0.909702 megs/sec

BTW, why would the first incorrectly function in kernel 2.2?  A bug
feature?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Alan Cox]

> heh.  It'd go along very well with the current /.post:
>   Kernel Fork for Big Iron?
>  Posted by Hemos on Wednesday
>  September 27, @04:01PM
>  from the what-to-do dept.
> (http://slashdot.org/article.pl?sid=00/09/27/191243=thread)
> 
> *sigh*

It amuses me that the big big fork is always forgotten. ucLinux is a fork. 
Zero harm has been noticed for this. And if SGI do a for now divergent NUMA
port but keep it syscall compatible good for them. When the PC world catches
up we can merge 

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Russell King forks ARM Linux.u

[George France]

Hello Alan;

> I can see where his confusion arises, but yes you are right, 
> people need to be
> able to mix the 16x50 driver with the sa1100 driver. The ppc 
> people went through
> fixing this. 

Yes you should be able to mix 16x50 chips with sa1100 chips. That is not the
issue. I believe that people can place any mixture of IC's on a PCB. 

> 
> HPA can I suggest the description for major 4 minor 64+ is 
> amended to be clear
> that its the 16x50 driver.

That may help others but it is still not the issue.

> 
> The proper way to manage ramdisks like that is to open each 
> possible set of
> ports and find which one fits your need - or of course you 
> can use devfs which
> for an embedded setup with flash based root may in fact be a 
> very attractive
> solution for other reasons too
>

We have thought of the above solutions and I believe that Erik Mouw has a
one line fix that will make everybody happy about the serial port. IMHO, the
current problem is that Russell gets too angry to talk about this issue. I
believe that no problem can be solved with a flame war going on. That is why
I decide to stop speaking with him about the serial port issue. He then
decided to block the e-mails. So here we are.

Best Regards,


--George


> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.u

[Alan Cox]

> believe that no problem can be solved with a flame war going on. That is why
> I decide to stop speaking with him about the serial port issue. He then
> decided to block the e-mails. So here we are.

Well if you arent speaking to him, then it doesnt matter if he blocks your
emails..

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Eli Carter]

Dan Hollis wrote:
> 
> On Wed, 27 Sep 2000, Russell King wrote:
> > Alan Cox writes:
> > > So is there a URL with the whole discussion on. It looks like a fun read ?
> > Have a look at the linux-arm-kernel archive at
> >  http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/
> > for the thread:
> >  Re: information request about serial driver
> 
> Any bets how long before /. picks this up and starts whipping lusers
> into a frenzy? A little bit of rewriting, deliberate fact omission,
> misquoting, and misleading headline. Voila, a /. "news" post.
> 
> -Dan

heh.  It'd go along very well with the current /.post:
Kernel Fork for Big Iron?
 Posted by Hemos on Wednesday
 September 27, @04:01PM
 from the what-to-do dept.
(http://slashdot.org/article.pl?sid=00/09/27/191243=thread)

*sigh*

Eli 
. "To the systems programmer, users and applications
Eli Carter  | serve only to provide a test load."
[EMAIL PROTECTED] `-- (random fortune)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Posting to this list without 500 bounces?

[Mike A. Harris]

This message may be seen by some to be OT, but it concerns
replying to messages from this specific mailing list, so I'm
asking it here.

My ISP's smtp is in ORBS and they don't seem to give a shit, and
mails to this list get 50 bouncebacks because of it.  So, I set
up my local MTA to send directly from home, instead of via the
ISP's SMTP.  I figured despite the slowness, it would solve the
problem.  Now I'm getting back all sorts of bounces from machines
blocking using something at "www.mail-abuse.org/dul" which
appears at a glance to be some list of all ISP's dialup modems or
something - meaning using my dialup machine with my own MTA is
going to be just as bad or worse..  SIGH.

Short of switching ISP's, is there some recommended way to get
mail out to the list without getting blocked by drop dead spam
filters?  Please feel free to throw me at another list that is
more appropriate, or flame away, or whatever..  I'd just like to
get this stupid MTA problem over with so I don't get 50 bounces
due to ORBS blockers, etc..

For the record, even though it is killing me right now, I agree
with the usage of ORBS and similar services for privacy and spam
blocking.  Feel free to flame me for that too.  ;o)

Again, sorry if you feel this is OT, but I don't have this
problem on other lists, and someone here likely has a good
answer.



--
 Mike A. Harris  -  Linux advocate  -  Open source advocate
   Copyright 2000 all rights reserved
   --
If you're interested in computer security, and want to stay on top of the
latest security exploits, and other information, visit:

http://www.securityfocus.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Russell King <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Alan Cox writes:
> > > now. IMHO, today he lost it, declaring that he was going to block all
> > > e-mails from Compaq, which means he can not recieve any more ARM Linux
> > > patches from us.  I have tried every method that I know of, to work with
> > 
> > So is there a URL with the whole discussion on. It looks like a fun read ?
> 
> Have a look at the linux-arm-kernel archive at
> 
>  http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/
> 
> for the thread:
> 
>  Re: information request about serial driver
> 

For what it's worth, the SA1100 serial driver has been registered with
me on the Low-Density Serial Ports major (204) as /dev/ttySA0-2 (minor
5-7).

Russ is 100% correct that different drivers shouldn't use the
same device numbers, unless they are:

a) mutually exclusive,
b) interface compatible, *AND*
c) handle all arbitration necessary.

If (a), (b) and (c) are all satisfied, it is often justified to share
device numbers and device nodes.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.u

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > > So is there a URL with the whole discussion on. It looks like a fun read ?
> > Have a look at the linux-arm-kernel archive at
> >  http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/
> 
> I can see where his confusion arises, but yes you are right, people need to be
> able to mix the 16x50 driver with the sa1100 driver. The ppc people went through
> fixing this. 
> 
> HPA can I suggest the description for major 4 minor 64+ is amended to be clear
> that its the 16x50 driver.
> 

Check.

> The proper way to manage ramdisks like that is to open each possible set of
> ports and find which one fits your need - or of course you can use devfs which
> for an embedded setup with flash based root may in fact be a very attractive
> solution for other reasons too

Actually, opening /dev/console is probably what you really want to do.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Timur Tabi]

** Reply to message from [EMAIL PROTECTED] on Wed, 27 Sep 2000 16:15:31
-0500


> But where's the advantage in using C++?  Plain old C has served admirably in
> UNIX and Linux development since the very beginning.  What more can C++ offer
> for driver development that outweighs the reduced accessibility of the code to
> those of us who are more proficient in C?

Well, people said the same thing to me when I started writing OS/2 drivers in
C++.  Nowadays, it's very common for non-*nix operating systems, especially
Windows.

The real advantage comes when you're writing a driver where the design is
inherently object-oriented.  I can't give an example in Linux, because I've
only been writing Linux drivers for 6 months, but in OS/2, there are tons of
places where a little OO lovin' goes a long way.  My initial use was in
multimedia drivers.  In OS/2, the adio drivers need to keep track of multiple
"streams" of audio data.  OS/2's advanced multimedia subsystem lets multiple
applications open audio streams simultaneously, and the driver has to keep
track of them.  If it has the hardware, it can play the streams simultaneously.
 Otherwise, it has to manage stopping one stream to play the other.

I've oversimplified it, but that's the general idea.

This design is inherently object-oriented.  The old C code for audio drivers
was horribly convoluted.  When I rewrote it in C++, there was less code, it was
easier to maintain, and ther resulting binary was actually smaller and faster!
And that's all because the language fit the design better.






-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Russell King forks ARM Linux.

[George France]

Hello Mike;

> Ok.  I didn't mean to imply anything..  It just wasn't clear, and
> due to the nature of the discussion, it seemed that it might have
> been a private message..
> 

No problem. I should have took more time in writing my e-mail and inserted
the headers.

Best Regards,


--George

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Russell King forks ARM Linux.

[Mike A. Harris]

On Wed, 27 Sep 2000, George France wrote:

>Date: Wed, 27 Sep 2000 17:22:27 -0400
>From: George France <[EMAIL PROTECTED]>
>To: 'Mike A. Harris' <[EMAIL PROTECTED]>,
> George France <[EMAIL PROTECTED]>
>Cc: Linux Kernel <[EMAIL PROTECTED]>
>Content-Type: text/plain;
>   charset="iso-8859-1"
>Subject: RE: Russell King forks ARM Linux.
>
>Relax. Russel posted this to a public mailing list.

Ok.  I didn't mean to imply anything..  It just wasn't clear, and
due to the nature of the discussion, it seemed that it might have
been a private message..

TTYL


--
 Mike A. Harris  -  Linux advocate  -  Open source advocate
   Copyright 2000 all rights reserved
   --
"A Firewall is really much like a sophisticated traffic cop; it detects and
stops unauthorized or suspicious movement in or out of the network. But
security is more than a Firewall; it's a process. You can't just put in a
Firewall and think you're secure."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.u

[Alan Cox]

> > So is there a URL with the whole discussion on. It looks like a fun read ?
> Have a look at the linux-arm-kernel archive at
>  http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/

I can see where his confusion arises, but yes you are right, people need to be
able to mix the 16x50 driver with the sa1100 driver. The ppc people went through
fixing this. 

HPA can I suggest the description for major 4 minor 64+ is amended to be clear
that its the 16x50 driver.

The proper way to manage ramdisks like that is to open each possible set of
ports and find which one fits your need - or of course you can use devfs which
for an embedded setup with flash based root may in fact be a very attractive
solution for other reasons too

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Dan Hollis]

On Wed, 27 Sep 2000, Russell King wrote:
> Alan Cox writes:
> > So is there a URL with the whole discussion on. It looks like a fun read ?
> Have a look at the linux-arm-kernel archive at
>  http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/
> for the thread:
>  Re: information request about serial driver

Any bets how long before /. picks this up and starts whipping lusers
into a frenzy? A little bit of rewriting, deliberate fact omission,
misquoting, and misleading headline. Voila, a /. "news" post.

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Russell King forks ARM Linux.

[George France]

Eric Mouw from the LART group will be posting the whole thing in a little
while.

Patience.

--George

> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 27, 2000 5:12 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Russell King forks ARM Linux.
> 
> 
> > now. IMHO, today he lost it, declaring that he was going to 
> block all
> > e-mails from Compaq, which means he can not recieve any 
> more ARM Linux
> > patches from us.  I have tried every method that I know of, 
> to work with
> 
> So is there a URL with the whole discussion on. It looks like 
> a fun read ?
> 
> > 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Russell King forks ARM Linux.

[George France]

Relax. Russel posted this to a public mailing list.

--George

> If that was a personal email from him to you (ie: not public)
> then it was very distasteful and disrespectful of you to post it
> here publically.  You should have at least quoted the header
> lines to make it clear...
> 
> Just my $0.02
> 
> 
> --
>  Mike A. Harris  -  Linux advocate  -  Open source advocate
>Copyright 2000 all rights reserved
>--
> Want to try a new high performance open source web server?  
> Try Caudium!
> http://caudium.orghttp://caudium.sourceforge.net
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Russell King forks ARM Linux.

[George France]

Russell;
> 
> George France writes:
> > As you probably know Russell King is the maintainer of ARM 
> Linux.  Him and I
> > have been debating how serial ports should be handled on an 
> off for months
> > now. IMHO, today he lost it,
> 
> Please note that at every instance, George has totally 
> ignored my suggestions
> and advice.  I have ended up taking this last straw to 
> prevent any further
> flame wars or other nastyness between us.

Every instance??? I think this is an exaggeration, don't you? If you really
want to prevent a flame war stop poking at me.

As I said in my last message to you, I am tired of arguing with you. 

--George

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Russell King]

Alan Cox writes:
> > now. IMHO, today he lost it, declaring that he was going to block all
> > e-mails from Compaq, which means he can not recieve any more ARM Linux
> > patches from us.  I have tried every method that I know of, to work with
> 
> So is there a URL with the whole discussion on. It looks like a fun read ?

Have a look at the linux-arm-kernel archive at

 http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/

for the thread:

 Re: information request about serial driver
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Wayne . Brown]

But where's the advantage in using C++?  Plain old C has served admirably in
UNIX and Linux development since the very beginning.  What more can C++ offer
for driver development that outweighs the reduced accessibility of the code to
those of us who are more proficient in C?

But then, I'm just an old reactionary who still isn't sure ANSI C was such a big
improvement over K





Timur Tabi <[EMAIL PROTECTED]> on 09/27/2000 03:35:19 PM

To:   unlisted-recipients: ;(no To-header on input)
cc:   Linux Kernel <[EMAIL PROTECTED]> (bcc: Wayne
  Brown/Corporate/Altec)

Subject:  Re: Linux kernel modules development in C++



Well, that's not much of answer.  It certainly doesn't mean anything to people
who have port drivers with tens of thousands of lines of code, all in C++.

I haven't tried C++ in Linux drivers myself, but I assume it can't be any more
difficult than what I had to do for OS/2.  Five years ago (imagine that - OS/2
is years ahead of Linux in this regard), I hacked up a method for getting C++
code to compile into an OS/2 device driver.  I had to write some extra code,
but it was really no problem.

Sure, I couldn't use exception handlers, but so what?  All I needed to do was
define malloc() and free(), and I could create and destroy objects whenever I
wanted.  In fact, you don't even need malloc() and free() - the C++ language
allows you to redined new and delete on a per-class basis.

Then I created some stub functions that would normally be called under an error
condition (like a missing virtual method in a subclass).  In fact, the linker
did all the work in this case - when I tried to link my driver with no runtime,
it gave me a nice list of missing functions, and all I had to do was create
stubs for them.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Mike A. Harris]

On Wed, 27 Sep 2000, George France wrote:

>Greetings;
>
>As you probably know Russell King is the maintainer of ARM Linux.  Him and I
>have been debating how serial ports should be handled on an off for months
>now. IMHO, today he lost it, declaring that he was going to block all
>e-mails from Compaq, which means he can not recieve any more ARM Linux
>patches from us.  I have tried every method that I know of, to work with
>him, but he has cut off all commutations. So starting tomorrow, we will be
>submitting patches directly to the kernel mailing list, since Russell will
>not even receive our e-mails. I will also be setting up an ARM mailing list
>and web pages, for those that wish to participate. It is too bad that
>Russell has decided to create a fork in the ARM Linux tree. It is his
>choice.
>
>Attached is his e-mail for the curious.

If that was a personal email from him to you (ie: not public)
then it was very distasteful and disrespectful of you to post it
here publically.  You should have at least quoted the header
lines to make it clear...

Just my $0.02


--
 Mike A. Harris  -  Linux advocate  -  Open source advocate
   Copyright 2000 all rights reserved
   --
Want to try a new high performance open source web server?  Try Caudium!
http://caudium.orghttp://caudium.sourceforge.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Alan Cox]

> now. IMHO, today he lost it, declaring that he was going to block all
> e-mails from Compaq, which means he can not recieve any more ARM Linux
> patches from us.  I have tried every method that I know of, to work with

So is there a URL with the whole discussion on. It looks like a fun read ?

> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Timur Tabi]

** Reply to message from Alan Cox <[EMAIL PROTECTED]> on Wed, 27 Sep
2000 22:00:54 +0100 (BST)


> > I have written the Windows platform version in C++ using Numega's tools
> > encapsulating the driver code in classes.
> > More of this classes isn't OS specific and it work well in any OS.
> 
> And do you rely on any exception throwing ?
> 
> If you use no exceptions (including thus using new and other constructors that
> allocate) you should be ok.

I don't think any OS supports exception handling in a driver.  It wouldn't make
much sense, since there's no way for a driver to really "exit" (which is the
ultimate destination of the exception).

By the way, new and delete are NOT exceptions.  They are simply wrappers for
malloc() and free().  Just define your own malloc and free (they can be
wrappers for a kernel memory allocation API, or you can write your own heap
manager), and new and delete work just fine.



-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Timur Tabi]

** Reply to message from Horst von Brand <[EMAIL PROTECTED]> on Wed, 27 Sep
2000 16:50:12 -0400


> I'd say it is important specifically in device drivers, and less so
> elsewhere ;-)

Yes, it's more important, but I've looked at the assembly code that my C++
compiler generates, and it's very clean.  In fact, when you're writing code
that by design is OO, then using C++ tends to generate better code, not worse,
since the language more closely matches the design.

> A couple of points:
> 
> - The kernel is C, mixing in C++ for no *real* good reason is just making
>   it harder to work on.

True, but I'm not advocating doing it for no real reason.  I'm advocating using
C++ for code that is OO by design.  My OS/2 device drivers are a mix of C and
C++, wherever appropriate.

> - The work you do to match the kernel's object model to C++ is strictly
>   wasted effort: The kernel's interfaces _do_ change, sometimes radically,
>   and you'll have to keep up

But that applies to C code as well.  In fact, the #2 gripe I hear about Linux
development is how the API's change so often and without any regard to existing
code that depends on it.  (#1 gripe: the dearth of good development tools).

> - The idea of reusing code from other OSes with a very different internal
>   layout will only make the point above even worse

Not always true.  Some drivers, like complex PCI audio drivers, are mostly
OS-independent.  They get some data from the OS, and then spend 90% of their
code just talking to the hardware.

> - History shows that no kludged-on C++ code will show up in the standard
>   kernel, so you loose the main advantage Linux gives you: Hundereds of
>   other people that fix bugs and port forward for you

True, if you want to write a driver that goes into the kernel, you need to
conform to Linus' whims^H^H^H^H^Hstandards.  But considering how difficult it
is to get a driver into the kernel anyway, it often doesn't make a difference.
I don't ever expect any of my Linux drivers to make it into the kernel, and I
write them in C.

> 
> And again:
> 
> - Your driver won't be huge, most of the OO advantages won't show

Not true in my experience.  My OO drivers have been comparble in size to their
C equivalents, and sometimes smaller because of the better code reuse that C++
promotes.

> - You don't have anywhere to inherit from sanely (sure, you can try to
>   kludge C++ classes over VFS, or the interface to block drivers; but they
>   won't be native C++ classes, so much of the benefit is lost, plus the
>   effort invested in the wrappers is wasted)

A matter of opinion.  If you have to maintain a dozen drivers of the same
class, then it may be worthwhile to write a small set of wrappers, and then do
everything in C++.  Again, this assumes that the design is OO to begin with.



-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Russell King forks ARM Linux.

[Russell King]

George France writes:
> As you probably know Russell King is the maintainer of ARM Linux.  Him and I
> have been debating how serial ports should be handled on an off for months
> now. IMHO, today he lost it,

Please note that at every instance, George has totally ignored my suggestions
and advice.  I have ended up taking this last straw to prevent any further
flame wars or other nastyness between us.

I therefore believe that it is in the greater good for the ARM Linux community
that discussions between George France and myself cease.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] mtrr.c for linux-2.4.0-test9-pre7

[Alan Cox]

> On mtrr.c, it assume that CPU is CyrixIII when cpuid is 0x06XX, and
> try to use intel compatible MTRR, so Cyrix MII with MTRR can't work.

Oops it shouldnt fall through any more. My fault

> Here is the ad hoc patch.

And here is a non AdHoc one (the Cyrix III reports itself as CENTAUR which
makes sense since they built it and are now like Cyrix part of VIA)

Fixed in my 2.2 tree as well



--- arch/i386/kernel/mtrr.c~Fri Sep 15 12:42:22 2000
+++ arch/i386/kernel/mtrr.c Wed Sep 27 21:05:41 2000
@@ -440,6 +440,7 @@
/*break;*/
   case X86_VENDOR_CYRIX:
/*  Cyrix have 8 ARRs  */
+   return 8;
   case X86_VENDOR_CENTAUR:
 /*  and Centaur has 8 MCR's  */
if(boot_cpu_data.x86==5)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Alan Cox]

> I have written the Windows platform version in C++ using Numega's tools
> encapsulating the driver code in classes.
> More of this classes isn't OS specific and it work well in any OS.

And do you rely on any exception throwing ?

If you use no exceptions (including thus using new and other constructors that
allocate) you should be ok.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

APM Problems

[Tom Sightler]

Hi All,

I'm having a problem related to APM on my Dell Inspiron 5000e (just arrived a few 
days ago).  I installed Redhat 7.0 and upon reboot was immediately greeted by 
scrolling oops screens.  The system did boot on up and upon further examintation 
I found the errors were caused by the attempt to start apmd.  Acutally, any 
access to /proc/apm would generate a non-fatal oops (general protection fault).

I compiled a standard 2.2.17 and 2.4.0-test9-pre7 but both experience exactly the 
same symptom, any access to /proc/apm and you get an oops.

A check of the linux laptop list indicated that other owners of the Inspiron 
5000e have this same problem so I thought it might be worthy to report here.

I did try ACPI support in 2.4.0-test9-pre7 and was able to get it to work, at 
least in regards to sleep and resume, but I loose functions like battery alerts 
(it doesn't appear the current linux acpi supports battery status, but I could be 
brain dead here).

Anyway, all this worked fine on my older 5000, and on my APM desktop at home, so 
it does seem to be somewhat unique to this model Dell.  Any thoughts on how to 
debug this.  I'll gladly gather oops info and post it here, or help in any other 
way.

Any other thoughts?

Later,
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Russell King forks ARM Linux.

[George France]

Greetings;

As you probably know Russell King is the maintainer of ARM Linux.  Him and I
have been debating how serial ports should be handled on an off for months
now. IMHO, today he lost it, declaring that he was going to block all
e-mails from Compaq, which means he can not recieve any more ARM Linux
patches from us.  I have tried every method that I know of, to work with
him, but he has cut off all commutations. So starting tomorrow, we will be
submitting patches directly to the kernel mailing list, since Russell will
not even receive our e-mails. I will also be setting up an ARM mailing list
and web pages, for those that wish to participate. It is too bad that
Russell has decided to create a fork in the ARM Linux tree. It is his
choice.

Attached is his e-mail for the curious.

Best Regards,


--George

George France,  [EMAIL PROTECTED]
Cambridge Research Laboratory, Compaq Computer Corporation
One CambridgecenterMS: CRL
Cambridge, MA 02142 USA


> Since this issue raises your blood pressure to an explosive level, I will
> not bother you again. I can handle this without you.

And thus you shall.  I shall not be accepting anything further from you.
Call this what you will, but you have brought this on yourself and your
organisation.  I am NOT going to work with incompetent selfish people who
refuse to listen to reason.

Good luck, we'll benefit without your uninformed arguments.

>From this point on, I shall be blocking you and your companies email
addresses.
I don't want to hear from you ever again.  You're not worth the bandwidth
you
waste.

Appologies in advance to anyone at the old crl.dec.com domain who can listen
to reason, I've had enough of this shit.
   _
  |_| - ---+---+-
  |   |Russell King   [EMAIL PROTECTED]  --- ---
  | | | |http://www.arm.linux.org.uk//  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |

___
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Horst von Brand]

Timur Tabi <[EMAIL PROTECTED]> said:
> ** Reply to message from Tigran Aivazian <[EMAIL PROTECTED]> on Wed, 27 Sep
> 2000 20:10:49 +0100 (BST)

[...]

> > at the bottom of each message there is a url to lkml FAQ - have you read
> > it? It should say (I haven't read it myself but it _should_, Richard you
> > hear this? :) plainly that Linux (or any UNIX) kernel development in C++
> > is a very bad idea and explain why. Because C++ is not yet a mature
> > programming language for tasks where precise knowledge of the generated
> > code is required (and probably will never be). Think of C programming (in
> > the kernel) simply as an assembly programming but using compiler as a
> > useful shortcut generator, instead of typing tedious (and most
> > importantly, arch-dependent!) sequences of instructions. Just a way to
> > save time, and still remain in total control of what the resulting code
> > will do and precisely how it will do it.

> Why is that important?  Sure, the kernel itself may need that level of
> control, but 90% of device drivers don't!  As long as you have a decent
> C++ compiler (one that creates clean code, like Watcom's does), and you
> don't try to use esoteric features like exception handling, it should
> work just fine.

I'd say it is important specifically in device drivers, and less so
elsewhere ;-)

A couple of points:

- The kernel is C, mixing in C++ for no *real* good reason is just making
  it harder to work on.
- The work you do to match the kernel's object model to C++ is strictly
  wasted effort: The kernel's interfaces _do_ change, sometimes radically,
  and you'll have to keep up
- The idea of reusing code from other OSes with a very different internal
  layout will only make the point above even worse
- History shows that no kludged-on C++ code will show up in the standard
  kernel, so you loose the main advantage Linux gives you: Hundereds of
  other people that fix bugs and port forward for you

And again:

- Your driver won't be huge, most of the OO advantages won't show
- You don't have anywhere to inherit from sanely (sure, you can try to
  kludge C++ classes over VFS, or the interface to block drivers; but they
  won't be native C++ classes, so much of the benefit is lost, plus the
  effort invested in the wrappers is wasted)
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Timur Tabi]

** Reply to message from Tigran Aivazian <[EMAIL PROTECTED]> on Wed, 27 Sep
2000 20:10:49 +0100 (BST)


> at the bottom of each message there is a url to lkml FAQ - have you read
> it? It should say (I haven't read it myself but it _should_, Richard you
> hear this? :) plainly that Linux (or any UNIX) kernel development in C++
> is a very bad idea and explain why. Because C++ is not yet a mature
> programming language for tasks where precise knowledge of the generated
> code is required (and probably will never be). Think of C programming (in
> the kernel) simply as an assembly programming but using compiler as a
> useful shortcut generator, instead of typing tedious (and most
> importantly, arch-dependent!) sequences of instructions. Just a way to
> save time, and still remain in total control of what the resulting code
> will do and precisely how it will do it.

Why is that important?  Sure, the kernel itself may need that level of control,
but 90% of device drivers don't!  As long as you have a decent C++ compiler
(one that creates clean code, like Watcom's does), and you don't try to use
esoteric features like exception handling, it should work just fine.


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Timur Tabi]

** Reply to message from "Richard B. Johnson" <[EMAIL PROTECTED]> on Wed,
27 Sep 2000 15:13:45 -0400 (EDT)


> > I want to develop a linux kernel module in C++ but I don't find
> > makefiles and/or sorce files examples to do this.
> >
> 
> Use the correct tool for the job. The Linux kernel uses 'C' and assembly.

Well, that's not much of answer.  It certainly doesn't mean anything to people
who have port drivers with tens of thousands of lines of code, all in C++.

I haven't tried C++ in Linux drivers myself, but I assume it can't be any more
difficult than what I had to do for OS/2.  Five years ago (imagine that - OS/2
is years ahead of Linux in this regard), I hacked up a method for getting C++
code to compile into an OS/2 device driver.  I had to write some extra code,
but it was really no problem.

Sure, I couldn't use exception handlers, but so what?  All I needed to do was
define malloc() and free(), and I could create and destroy objects whenever I
wanted.  In fact, you don't even need malloc() and free() - the C++ language
allows you to redined new and delete on a per-class basis.  

Then I created some stub functions that would normally be called under an error
condition (like a missing virtual method in a subclass).  In fact, the linker
did all the work in this case - when I tried to link my driver with no runtime,
it gave me a nice list of missing functions, and all I had to do was create
stubs for them.




-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: AW: Given an image, how can show its config?

[James Sutherland]

On Wed, 27 Sep 2000, David Ford wrote:

> James Sutherland wrote:
> 
> > No. I am assuming you are installing the kernel on the machine you do
> > "make modules_install" on. Obviously it is possible to install a different
> > kernel image of the same version without updating the modules - but if you
> > do so, expect nasty things to happen anyway if you're using modules!
> 
> I normally compile on one machine and distribute it.  This isn't a viable
> solution.

Unless you omit the modules directory, that's not a problem.

> > In more complex cases, find a more complex solution - this is a nice
> > simple solution which works for the typical case of building and
> > installing a kernel!
> >
> > If you are DIY upgrading a box's kernel, this solution works fine. If
> > you're maintaining a distribution, you should be able to use this solution
> > without much extra effort. If you are building kernels to DIY upgrade
> > other machines, and don't bother copying /lib/modules/`uname -r` then you
> > need to find another solution. I doubt this scenario is common enough to
> > justify denying the vast majority of Linux users this facility!
> 
> Linus tends to go for the 'perfect' solution, not the 'almost' solution.  I
> fully agree.  uname -r simply doesn't have the granularity necessary.

It's worked perfectly well so far.


James.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Timur Tabi]

** Reply to message from Horst von Brand <[EMAIL PROTECTED]> on Wed, 27 Sep
2000 15:31:51 -0400


> Your problem is that you can't use anything of C++ that needs runtime
> support inside the kernel (there goes new() and friends), exception
> handling is out of the question (bye, bye, throw() et al), and (in case you
> hadn't thought of it) libstdc++ is way out of line (no fancy data
> structures or algorithms).

So what?  The same is true for any operating system, and that's why driver
programmers make their own runtime.  That's what I did for OS/2, and it works
great.  You just create your own versions of malloc() and free() and a bunch of
other small functions that the compiler expects to be present, and link it in.
I don't see the problem.

Practically every other OS supports drivers in C++.  There's nothing wrong with
writing drivers in C++, you just need to write some runtime library routines.
Your making it sound as if C++ compilers emit tons of junk that won't work in
the kernel, and that's absurd. 

Nothing needs to be changed in the kernel to support C++.  You just need to
write a bunch of wrappers for everything in the kernel that you use, and that's
nothing new.  C++ programmers are used to this, because that's how you call any
operating system API.


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

NFS problems - 2.2.16 (RedHat)

[jpranevich]

Hello,

(Lycos hat is now in the *on* position.)

I maintain a decent number of Linux boxes, generally PII boxes with 256M - 1024M
of RAM. These boxes work as web servers, but pull much of their data over NFS.
(The NFS servers are Network Appliances.) Under Linux 2.2.16, I will
occasionally see NFS hangs. That is, a NFS mount point will die on a single box
(or on multiple boxes), any processes that attempt to access that point will
freeze, etc. (df, for instance, will never return. Eventually, I can ^C out of
it.) This *ONLY* happens on uniprocessor boxes, never on any of my dual
machines.

The kernel log doesn't report anything out of the ordinary for our boxes. We do
occasionally get messages that we momentarily can't talk to one of the NFS
servers or another, but those errors happen on both the uniprocessor and
multi-processor boxes.

So, is this a known issue with 2.2.16 NFS? Does the NFS backport in 2.2.18 do
anything to resolve these problems? Is there a dedicated NFS mailing list that I
haven't found yet?

Thanks so much,

Joe Pranevich
Lycos Production Support
[EMAIL PROTECTED]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] mtrr.c for linux-2.4.0-test9-pre7

[IIZUKA Daisuke]

Hi. I found a bug on test9-pre7 mtrr.c about Cyrix MII.

When I use linux-2.4.0-test9-pre4 with MTRR enable, it works fine.
But when I try to boot linux-2.4.0-test9-pre7,
GPF occur after "mtrr: v1.36" message, and kernel freeze.

My Cyrix MII's cpuid is 0x0628, and CyrixIII's cpuid seems to be 0x0660.

On mtrr.c, it assume that CPU is CyrixIII when cpuid is 0x06XX, and
try to use intel compatible MTRR, so Cyrix MII with MTRR can't work.

Here is the ad hoc patch.

--- linux-2.4.0-test9-pre7/arch/i386/kernel/mtrr.c.dist Thu Sep 28 03:15:11 2000
+++ linux-2.4.0-test9-pre7/arch/i386/kernel/mtrr.c  Thu Sep 28 03:53:30 2000
@@ -461,7 +461,8 @@
/*  Cyrix have 8 ARRs  */
   case X86_VENDOR_CENTAUR:
 /*  and Centaur has 8 MCR's  */
-   if(boot_cpu_data.x86==5)
+   if(boot_cpu_data.x86==5
+  || (boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model < 6))
return 8;
/*  the cyrix III has intel compatible MTRR */
if(boot_cpu_data.x86==6)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Horst von Brand]

=?iso-8859-1?Q?Abel_Mu=F1oz_Alcaraz?= <[EMAIL PROTECTED]> said:

>   I want to develop a linux kernel module in C++ but I don't find
> makefiles and/or sorce files examples to do this.

Your problem is that you can't use anything of C++ that needs runtime
support inside the kernel (there goes new() and friends), exception
handling is out of the question (bye, bye, throw() et al), and (in case you
hadn't thought of it) libstdc++ is way out of line (no fancy data
structures or algorithms). What is left is not very much... and it won't
make much of a difference in a driver, which by its nature is typically
smallish. You have no place to go to find stuff you could inherit from, so
you'd have to recreate all the supporting object infrastructure in the
kernel in C++, or port it somehow from C (the object model inside the
kernel doesn't really map into C++'s concepts cleanly!). Not worth the
effort, AFAIKS.

The kernel is written in plain gcc C (this is _not_ your ANSI C!), it uses
identifiers that are reserved words in C++. And that won't change anytime
very soon. But that would get you only to the point of using C++'s
procedural aspects. To make it really worthwhile to write parts of the
kernel in C++, the kernel would have to be redesigned from the ground up
for C++. Nobody has ever volunteered (or even just hinted that they could
be persuaded to volunteer) to do this job, and this discussion comes up
each four months or so.
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Linux kernel modules development in C++

[Abel Munoz Alcaraz]

I want to develop a platform-independent driver (Windows 9x/NT/2000, Linux,
Mac OS,...).
I have written the Windows platform version in C++ using Numega's tools
encapsulating the driver code in classes.
More of this classes isn't OS specific and it work well in any OS.

This is the reason because I want to do this. I want reuse a lot of code.

Thanks.

-Abel.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Albert D. Cahalan
Sent: miercoles, 27 de septiembre de 2000 21:10
To: Abel Munoz Alcaraz
Subject: Re: Linux kernel modules development in C++


>   I want to develop a linux kernel module in C++

Why?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Module unresolved symbol on 2.4.0-test8 SMP

[Sam Watters]

I'm getting the following error when trying to load a module under a
2.4.0-test8 SMP kernel:

[root@porsche13 themod-dev]# insmod themod.o
themod.o: unresolved symbol write_lock
themod.o: unresolved symbol read_lock

The module was compiled with the following options (in a
sub-sub-subdirectory of the kernel source):

 
gcc -Wall -Wstrict-prototypes -fomit-frame-pointer -pipe -march=i686
-fno-strict-aliasing  -D__SMP__ -DMODULE -D__KERNEL__ -DLINUX -Dlinux 
-DDEBUG -I../../../include -c themod.c 

This has me really puzzled.  I've checked out the file
include/asm/spinlock.h & gone so far as to introduce a compiler error
into the read_lock() inline function.  The compiler reported the error,
so I know that the read_lock() inline function is being seen when I
build the module.  However, I continue to get these unresolved symbol
errors when I try to load the module.

The compiler version I am using is:

egcs-1.1.2-30

I also tried gcc-2.7.3.2 and received the same error.

The module loads and works fine under the uniprocessor 2.4.0-test8
kernel.

Any suggestions on what I am screwing up would be greatly appreciated.

 - Sam

Sam Watters
SGI
[EMAIL PROTECTED]
(651) 683-5647

See What's Possible!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Tigran Aivazian]

On Wed, 27 Sep 2000, Tigran Aivazian wrote:

> Hi Abel,
> 
> at the bottom of each message there is a url to lkml FAQ - have you read
> it? It should say (I haven't read it myself but it _should_, Richard you
> hear this? :) plainly that Linux (or any UNIX) kernel development in C++
> is a very bad idea and explain why. Because C++ is not yet a mature
> programming language for tasks where precise knowledge of the generated
> code is required (and probably will never be). Think of C programming (in
> the kernel) simply as an assembly programming but using compiler as a
> useful shortcut generator, instead of typing tedious (and most
> importantly, arch-dependent!) sequences of instructions. Just a way to
> save time, and still remain in total control of what the resulting code
> will do and precisely how it will do it.

just in case - I did intentionally omit the exception handling and garbage
collection things (and many other) as "obvious", i.e. just more reasons
why one should _not_ use C++ in the kernel.

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Richard B. Johnson]

On Wed, 27 Sep 2000, [iso-8859-1] Abel Muñoz Alcaraz wrote:

> Hi everybody,
> 
>   I want to develop a linux kernel module in C++ but I don't find
> makefiles and/or sorce files examples to do this.
>

Use the correct tool for the job. The Linux kernel uses 'C' and assembly.


Cheers,
Dick Johnson

Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Tigran Aivazian]

Hi Abel,

at the bottom of each message there is a url to lkml FAQ - have you read
it? It should say (I haven't read it myself but it _should_, Richard you
hear this? :) plainly that Linux (or any UNIX) kernel development in C++
is a very bad idea and explain why. Because C++ is not yet a mature
programming language for tasks where precise knowledge of the generated
code is required (and probably will never be). Think of C programming (in
the kernel) simply as an assembly programming but using compiler as a
useful shortcut generator, instead of typing tedious (and most
importantly, arch-dependent!) sequences of instructions. Just a way to
save time, and still remain in total control of what the resulting code
will do and precisely how it will do it.

Regards,
Tigran

 On Wed, 27 Sep 2000, Abel Muñoz Alcaraz wrote:

> Hi everybody,
> 
>   I want to develop a linux kernel module in C++ but I don't find makefiles
> and/or sorce files examples to do this.
>   When I compile the module, the gcc shows a lot of warnings.
>   I have tried to use 'extern "C" {}' in my source files, but the result is
> the same one.
> 
>   For example:
>   extern "C" {
>   #include 
>   }
> 
>   Can you help me?
> 
> Thanks in advance for your help.
> 
> -Abel.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux kernel modules development in C++

[Christoph Hellwig]

Abel Mu?oz Alcaraz <[EMAIL PROTECTED]> wrote:
> Hi everybody,

>   I want to develop a linux kernel module in C++ but I don't find makefiles
> and/or sorce files examples to do this.

Don't do that.
Search the list-archive for C++ and read why.

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Problem with 2.2.17 & DVD-RAM

[matt . nottingham]

At work we have the Panasonic 101 & 103 DVD-RAMs (which can read CDs,
DVDs, PDs & DVD-RAMs). We also work with NT. Under 2.2.14 (and before)
the DVD-RAM showed up as device sdb. This allowed us to read PD disks
(650MB MO disks) which were formated under NT as either "Super floppy"
or (I think) FAT disks. However there was a problem when using the
DVD-RAM with an ext2 filesystem as it did not recognise that there
was a media change, which ended with a reformat of the DVD-RAM disk
being required unless the cache was fluhed.

With the removal of the GHOST list, the DVD-RAM now shows up as sr0
(which makes more sense). However, we now cannot write to a "super
floppy" PD disk without trashing the disk. Reading seems to be OK, as
does creating zero length files, but creating anything bigger means
that the disk cannot be accessed under NT nor mounted again under
Linux. Also we can't mount FAT formatted PD disks as the sr devices
don't support partitions (but doing an fdisk to find where the
partition starts and then a dd to copy it to disk and mounting that
image through the loopback device worksbut isn't ideal...). But
the good news is that we can read our ext2 DVD-RAMs and that the media
changes are now noticed - no more corrupted DVD-RAM disks!

I've looked through the mailing list archives but haven't noticed
anyone reporting this problem. We're using the stock 2.2.x kernel with
the NFS3 patches on (& looking forward to 2.2.18!) with a mix of
Debian 2.2 & Redhat 6.1.

Thanks for any suggestions,

Matt Nottingham
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] vmfixes-2.4.0-test9-B2 - fixing deadlocks

[Andrea Arcangeli]

On Wed, Sep 27, 2000 at 12:25:44PM -0600, Erik Andersen wrote:
> Or sysinfo(2).  Same thing...

sysinfo structure doesn't export the number of active pages in the system.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] vmfixes-2.4.0-test9-B2 - fixing deadlocks

[Erik Andersen]

On Wed Sep 27, 2000 at 07:42:00PM +0200, Andrea Arcangeli wrote:
> 
> You should of course poll the /proc/meminfo. (/proc/meminfo works in O(1) in
> 2.4.x so it's just the overhead of a read syscall)

Or sysinfo(2).  Same thing...

 -Erik

--
Erik B. Andersen   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/