* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: John Stoffel @ 2004-01-26 4:26 UTC (permalink / raw)
To: John Stoffel
Cc: Andi Kleen, Adrian Bunk, Valdis.Kletnieks, Fabio Coatti,
Andrew Morton, Eric, linux-kernel
In-Reply-To: <16404.34836.753760.759367@gargle.gargle.HOWL>
Just a quick followup, but 2.6.2-rc2 also hung in the exact same spot,
after printing out the HighMem zone: line.
Falling back to 2.6.1-mm5 for now. More testing tomorrow evening when
I get a chance.
John
^ permalink raw reply
* [Qemu-devel] howto for win98
From: Alexandre Leclerc @ 2004-01-26 4:46 UTC (permalink / raw)
To: qemu-devel
Hi all,
I just saw this nice project on lwn and I would like to give it a try. Is
there any doc that explains clearly how I could created an image and install
win98 in it? I saw that it was tested and viewed win 3.1 screenshots, but I
can't find any simple step by step how to about it. I've read the doc, but
this is a bit confusing for me.
Thanks for your help. Nice project! It might be an open source solution
instead of vmware I'm using right now.
--
Alexandre Leclerc
_________________________________________________________________
Spam effektiv reduzieren - mit dem Hotmail-Junk-Filter!
http://www.msn.de/antispam/prevention/junkmailfilter Schluß mit Spam - MSN
hilft Ihnen hier weiter.
^ permalink raw reply
* Re: [ANNOUNCE] Cooperative Linux
From: JustFillBug @ 2004-01-26 3:57 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <40148C1C.5040102@vgertech.com>
On 2004-01-26, Nuno Silva <nuno.silva@vgertech.com> wrote:
>> Hello fellow developers, kernel hackers, and open source contributors,
>>
>> Cooperative Linux is a port of the Linux kernel which allows it
>> to run cooperatively under other operating systems in ring0 without
>> hardware emulation, based on very minimal changes in the architecture
>> dependent code and almost no changes in functionality.
>>
>> The bottom line is that it allows us to run Linux on an unmodified
>> Windows 2000/XP system in a practical way (the user just launches
>
> Very nice! Can we run two (or more) instances of Linux at the same time?
>
> When will you release a linux-as-host patch? :-)
>
How about a bare bone OS whose sole purpose is to run multiple OS on top
of it? A pure VM OS.
^ permalink raw reply
* Re: [ANNOUNCE] Cooperative Linux
From: Karim Yaghmour @ 2004-01-26 5:01 UTC (permalink / raw)
To: Dan Aloni; +Cc: Nuno Silva, Linux Kernel List
In-Reply-To: <20040126042631.GA401@callisto.yi.org>
Dan Aloni wrote:
> I can't say exactly when, but several people volunteered to work on this.
BTW, I've been looking at the code. Many of the tricks done for forcing
NT to share resources with Linux should be unnecessary for a Linux setup.
Also, the code apparently assumes only two OSes. You probably want to
check the detailed discussion I had written some time ago about how to
easily obtain an SMP cluster with Linux (N instances on separate CPUs
with very few code modifications required):
http://www.opersys.com/adeos/dox/practical-smp-clusters/practical-smp-clusters.html
Some of the code you've already written can be used as-is to this end.
The nanokernel side still needs some extending, but you've brought things
one step closer to completion.
On a UP system, instead of running just 2 instances, you can load a
nanokernel in a fixed RAM region and remap it in every instance's
virtual memory. You can then use a slightly modified kexec to start
independent images in different RAM regions. I had discussed this
with Eric at the last OLS and he was interested. The added
advantage with Adeos is that you could then share a single interrupt
pipeline among all OSes, and have different OSes manage different hardware
components. Of course, if you add the PCI allocation code I cover in the
above paper, you can then have things like two kernels independently
managing, for example, two seperate sets of ethernet card and SCSI disk.
There's some pretty cool stuff to be done here, away from the simple
virtual devices. You could also have a virtual ethernet layer which is
shared by all OS images, and then have a private network between all
OS instances. With Adeos, you can also have one kernel take care of
all hard-rt operations and another kernel take care of the soft-rt
operations. All of it is fairly hardware independent.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546
^ permalink raw reply
* Re: [ANNOUNCE] Cooperative Linux
From: Ben Pfaff @ 2004-01-26 4:59 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <slrnc193vo.42h.mozbugbox@mozbugbox.somehost.org>
JustFillBug <mozbugbox@yahoo.com.au> writes:
> How about a bare bone OS whose sole purpose is to run multiple OS on top
> of it? A pure VM OS.
For what it's worth, this has been done in the proprietary world
as successful commercial software, as VMware ESX Server. Might
want to have a look at that if you seriously contemplate
something like that.
--
Ben Pfaff
email: blp@cs.stanford.edu
web: http://benpfaff.org
^ permalink raw reply
* Re: [ANNOUNCE] Cooperative Linux
From: Karim Yaghmour @ 2004-01-26 5:04 UTC (permalink / raw)
To: JustFillBug; +Cc: linux-kernel
In-Reply-To: <slrnc193vo.42h.mozbugbox@mozbugbox.somehost.org>
JustFillBug wrote:
> How about a bare bone OS whose sole purpose is to run multiple OS on top
> of it? A pure VM OS.
How about reinventing the wheel:
http://www.opersys.com/adeos/index.html
The potential of reusing Dan's work on colinux to complete what Adeos
has already started seems rather clear.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546
^ permalink raw reply
* Re: [ANNOUNCE] Cooperative Linux
From: Nuno Silva @ 2004-01-26 5:06 UTC (permalink / raw)
To: JustFillBug; +Cc: linux-kernel
In-Reply-To: <slrnc193vo.42h.mozbugbox@mozbugbox.somehost.org>
Hi!
JustFillBug wrote:
>
>
> How about a bare bone OS whose sole purpose is to run multiple OS on top
> of it? A pure VM OS.
>
That's xen. You can learn more here:
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
Regards,
Nuno Silva
^ permalink raw reply
* Re: 2.6.1: data corrupton when recieving files > 1GB over network
From: Hans Spath @ 2004-01-26 5:05 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <5.1.0.14.2.20040111161640.014ad6c0@localhost>
On Sun, Jan 11, 2004 at 05:36:32PM +0100, I wrote:
> When I transfer files to my linux 2.6.1 box their content changes
> (tested via md5 sums).
> [no problem with Knoppix 3.2 (Linux 2.4.21-xfs)]
I've finally found the problem. It was a *hardware* problem.
The problem occured only with DMA activated for harddisks and the
Knoppix kernel doesn't do this by default.
(It was a bit strange, because it happend only when writing to disk
while having high network traffic, even after switching NIC and IDE
controler.)
I've exchanged the mainboard and now everything is working perfectly.
Sorry for wasting your time, folks.
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Andi Kleen @ 2004-01-26 5:04 UTC (permalink / raw)
To: John Stoffel
Cc: Andi Kleen, Adrian Bunk, Valdis.Kletnieks, Fabio Coatti,
Andrew Morton, Eric, linux-kernel
In-Reply-To: <16404.34836.753760.759367@gargle.gargle.HOWL>
> On node 0 totalpages: 196606
> DMA zone: 4096 pages, LIFO batch:1
> Normal zone: 192510 pages, LIFO batch:16
> HighMem zone: 0 pages, LIFO batch:1
Ok, it didn't oops. Just hung early. Probably needs some printks
to track it down.
And the problem really goes away when you disable -funit-at-a-time ?
-Andi
^ permalink raw reply
* Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
From: Steve Youngs @ 2004-01-26 5:06 UTC (permalink / raw)
To: Linux Kernel List
In-Reply-To: <20040125222242.A24443@mail.kroptech.com>
[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]
* Adam Kropelin <akropel1@rochester.rr.com> writes:
> On Mon, Jan 26, 2004 at 09:12:58AM +1000, Steve Youngs wrote:
>> * Linus Torvalds <torvalds@osdl.org> writes:
>>
>> > - doing proper refcounting of modules is _really_ really
>> > hard. The reason is that proper refcounting is a "local"
>> > issue: you reference count a single data structure. It's
>> > basically impossible to make a "global" reference count
>> > without jumping through hoops.
>>
>> Please understand that I coming from an _extremely_ naive perspective,
>> but why do refcounting at all? Couldn't the refcount be a simple
>> boolean?
> A boolean is just a one-bit reference count. If the maximum number of
> simultaneous 'users' for a given module is one, then a boolean will work.
> If there is potential for more than one simultaneous user then you need
> more bits.
Why? A module is either being used or it isn't, the number of uses
shouldn't even come into it.
>> I see the process working along these lines: When a module is loaded
>> into the kernel it (the module) exports a symbol (a function) that the
>> kernel can use for determining whether or not the module is still in
>> use.
> And how will the module know when it is or is not "in use"? By keeping
> a count of the number of current users, of course.
No, the number of current users wouldn't have any bearing on it whatsoever.
How each module does it would be up to the module itself. For an ethernet
card it could be while the card is associated with a IP; for a USB keyboard
it could be while the keyboard is plugged in; for a sound driver it could
be while anything is accessing the sound devices. etc etc.
I'm suggesting that the responsibility for determining when it is safe
to unload a particular module should lay with the module itself and
not with the kernel.
>> > - lack of testing.
>>
>> A moot point once the kernel can safely and efficiently do module
>> unloading.
> I don't follow your logic. Once it works we don't have to test it so
> therefore we never need to test it?
Possibly a poor choice of words on my part. What I meant was that
once the functionality goes into the kernel testing will happen on
every single Linux box in the land that has this future kernel. Some
of those users will report bugs if there are any. And some of those
users may even help to fix those bugs.
Also what I meant is that you can't test something that doesn't
exist.
>> > Unloading a module happens once in a blue moon, if even then.
>>
>> We get an awful lot of blue moons here.
> This moon's not worth barking at.
There are an awful lot of users out there who would disagree with you
on that. _One_ of the reasons that I believe that this moon is worth
barking at is:
If a module should never, in the normal course of events, be unloaded,
then there isn't _any_ point to being able to load them in the first
place. Not being able to unload them _totally_ defeats the purpose of
modules.
Yes, I could be wrong, I sure as anything don't know the full story,
but I'm not convinced that I am wrong yet.
> Several extremely bright people have tackled the problem and eventually
> concluded it's extremely hard to solve and generally not worth the
> trouble. It's time to let go.
Several extremely bright people thought Galileo was a heretic and a
fool.
Tell me that this problem is _impossible_ to solve and providing you
can show me _why_ it is impossible I'll speak no more on this
matter.
But if you tell me that this problem is too hard to solve, then I have
no alternative than to think: "you're not trying hard enough".
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| Ashes to ashes, dust to dust. |
| The proof of the pudding, is under the crust. |
|------------------------------<sryoungs@bigpond.net.au>---|
[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
From: Valdis.Kletnieks @ 2004-01-26 5:21 UTC (permalink / raw)
To: Steve Youngs; +Cc: Linux Kernel List
In-Reply-To: <microsoft-free.87hdyjs3h3.fsf@eicq.dnsalias.org>
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
On Mon, 26 Jan 2004 15:06:48 +1000, Steve Youngs <sryoungs@bigpond.net.au> said:
> > A boolean is just a one-bit reference count. If the maximum number of
> > simultaneous 'users' for a given module is one, then a boolean will work.
> > If there is potential for more than one simultaneous user then you need
> > more bits.
>
> Why? A module is either being used or it isn't, the number of uses
> shouldn't even come into it.
OK. There's 2 users of the module. The first one exits. How does it (or
anything else) know that it's NOT safe to just clear the in-use bit and clean
it up?
And how does the second one know it IS safe to clean up?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* girth? "Date Number"26947
From: rusebuehle @ 2004-01-26 5:24 UTC (permalink / raw)
To: sparclinux
REALLY lay the pipe to the next chick you screw...
http://byroad.sddse4fc.com/vp5
No more of this sort of material. Honoured in 24-48 hours.
http://diathermy.amilsdcx.com/a.html
chant bulldoze blinn sib eskimo berate chatty lightproof bugeyed lisa cottrell embellish sprite effete miniature intransigent deflate aryl eaten equity hammock committeeman toroid desmond worship demountable dichondra raoul crosstalk
pV
^ permalink raw reply
* never this cheap "Date Number"745826
From: brandeefleshman @ 2004-01-26 5:24 UTC (permalink / raw)
To: sparclinux
Really lay the PIPE to the next girl you screw...
http://spedwee.com/vp5
take off-
http://acronym.diffrs.com/a.html
experimentation trend demolition
^ permalink raw reply
* Re: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module
From: David S. Miller @ 2004-01-26 5:34 UTC (permalink / raw)
To: shmulik.hen; +Cc: netdev, bonding-devel
In-Reply-To: <E791C176A6139242A988ABA8B3D9B38A014C96A4@hasmsx403.iil.intel.com>
From: "Hen, Shmulik" <shmulik.hen@intel.com>
Date: Sun, 25 Jan 2004 14:28:51 +0200
> Please resend these two changes after he does a release.
Fair enough. What about 2.4 ?
Sure, send it once 2.4.26-preX starts up.
^ permalink raw reply
* Trouble with Cisco Airo MPI350 and kernel-2.6.1+
From: Warren Togami @ 2004-01-26 5:48 UTC (permalink / raw)
To: fedora-devel-list, linux-kernel, fabrice
IBM Thinkpad T41
Cisco Airo MPI350 802.11b Wireless
PCIID: 0x14b9 0xa504
Kernel: Fedora rawhide 2.6.1-1.57 (Based on 2.6.2-rc1)
http://bellet.info/~bellet/laptop/t40.html#wireless
http://bellet.info/~bellet/laptop/airo.c-2.6.1-mm2.diff
airo.ko does not support this Airo device, but with the addition of this
patch it recognizes the device.
airo: MAC enabled eth1 0:2:8a:df:50:fc
airo: Finished probing for PCI adapters
[root@ibmlaptop root]# iwconfig
eth0 IEEE 802.11-DS ESSID:"tsunami"
Mode:Managed Frequency:2.442GHz Access Point: FF:FF:FF:FF:FF:FF
Bit Rate:11Mb/s Tx-Power=20 dBm Sensitivity=0/0
Retry limit:16 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:176/0 Signal level:-105 dBm Noise level:-100 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:416 Missed beacon:0
<SNIP>
[root@ibmlaptop root]# iwconfig eth0 key 8208435e17
airo: Max tries exceeded waiting for command
PC4500_writerid: Write rid Error 65535
PC4500_writerid: Cmd=0121
airo: WEP_PERM set ffff
[root@ibmlaptop root]# iwconfig
<SNIP>
eth0 IEEE 802.11-DS ESSID:"tsunami"
Mode:Managed Frequency:2.442GHz Access Point: FF:FF:FF:FF:FF:FF
Bit Rate:11Mb/s Tx-Power=20 dBm Sensitivity=0/0
Retry limit:16 RTS thr:off Fragment thr:off
Encryption key:****-****-** Security mode:open
Power Management:off
Link Quality:176/0 Signal level:-105 dBm Noise level:-100 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:488 Missed beacon:0
I am guessing that the *'s rather than hex characters displayed are
because it is unable to read the key from the card. The card itself
appears to be completely inoperative. It was suggested to me to try
both "open" and "restricted" mode, both seem to not help the situation.
Any suggestions?
Warren Togami
wtogami@redhat.com
^ permalink raw reply
* Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
From: Steve Youngs @ 2004-01-26 5:55 UTC (permalink / raw)
To: Linux Kernel List
In-Reply-To: <200401260521.i0Q5LRha021370@turing-police.cc.vt.edu>
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
* Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
> On Mon, 26 Jan 2004 15:06:48 +1000, Steve Youngs <sryoungs@bigpond.net.au> said:
>> > A boolean is just a one-bit reference count. If the maximum number of
>> > simultaneous 'users' for a given module is one, then a boolean will work.
>> > If there is potential for more than one simultaneous user then you need
>> > more bits.
>>
>> Why? A module is either being used or it isn't, the number of uses
>> shouldn't even come into it.
> OK. There's 2 users of the module. The first one exits. How does
> it (or anything else) know that it's NOT safe to just clear the
> in-use bit and clean it up?
Because the 2nd user is still using the module so its in-use bit
should still be set. Remember that when the module was first loaded
it registered a function with the kernel for testing whether the
module is in use.
I must be overlooking something because I see the answer so clearly.
Maybe if someone could give me a real world example of a situation
where it'd be hard/impossible/unsafe to unload a module and I'll see
if my ideas can be applied.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| Ashes to ashes, dust to dust. |
| The proof of the pudding, is under the crust. |
|------------------------------<sryoungs@bigpond.net.au>---|
[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: [PATCH] oprofile per-cpu buffer overrun
From: Anton Blanchard @ 2004-01-26 5:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: Philippe Elie, linux-kernel, levon
In-Reply-To: <20040125200701.3c7b769a.akpm@osdl.org>
> It helps if the buffer size is a power of two, of course, but integer
> modulus is pretty quick.
If its something thats hit real hard, the way the modulus is done can
make a difference. We've seen it in various places (eg disabling tigon 1
support in the acenic changes the driver from using a variable to a
compile time constant and you can actually see it in the profile):
quickest == power of 2 compile time constant (results in a mask)
quickish == compile time constant (results in the multiplication by
an inverse trick)
slow == run time (results in a divide)
Of course you can do like the printk stuff and use a variable but
enforce a power of 2 value and & it.
Anton
--
unsigned long i, j, k;
int quickest()
{
j = i % 2;
}
int quickish()
{
j = i % 3;
}
int slow()
{
j = i % k;
}
--
quickest:
lis 9,i@ha
lwz 0,i@l(9)
lis 9,j@ha
rlwinm 0,0,0,31,31
stw 0,j@l(9)
blr
quickish:
lis 9,i@ha
lis 0,0xaaaa
lwz 11,i@l(9)
ori 0,0,43691
lis 9,j@ha
mulhwu 0,11,0
srwi 0,0,1
mulli 0,0,3
subf 11,0,11
stw 11,j@l(9)
blr
slow:
lis 9,i@ha
lis 11,k@ha
lwz 10,i@l(9)
lwz 9,k@l(11)
divwu 0,10,9
mullw 0,0,9
lis 9,j@ha
subf 10,0,10
stw 10,j@l(9)
blr
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Andrew Morton @ 2004-01-26 6:00 UTC (permalink / raw)
To: John Stoffel
Cc: ak, stoffel, Valdis.Kletnieks, bunk, cova, eric, linux-kernel
In-Reply-To: <16404.10496.50601.268391@gargle.gargle.HOWL>
"John Stoffel" <stoffel@lucent.com> wrote:
>
> Sure, the darn thing wouldn't boot, it kept Oopsing with the
> test_wp_bit oops (that I just posted more details about).
Does this fix the test_wp_bit oops?
--- 25/init/main.c~test_wp_bit-oops-fix 2004-01-25 15:29:53.000000000 -0800
+++ 25-akpm/init/main.c 2004-01-25 15:30:03.000000000 -0800
@@ -434,9 +434,9 @@ asmlinkage void __init start_kernel(void
}
#endif
page_address_init();
+ sort_main_extable();
mem_init();
kmem_cache_init();
- sort_main_extable();
if (late_time_init)
late_time_init();
calibrate_delay();
_
^ permalink raw reply
* Re: Problem with module-init-tools
From: Rusty Russell @ 2004-01-26 6:05 UTC (permalink / raw)
To: J.A. Magallon; +Cc: linux-kernel
In-Reply-To: <20040124222907.GA4072@werewolf.able.es>
On Sat, 24 Jan 2004 23:29:07 +0100
"J.A. Magallon" <jamagallon@able.es> wrote:
> Hi all...
>
> I have a problem with modprobe, 2.6.2-rc1-mm2, and agpgart.
>
> With 2.4, I had this setup to have agpgart loaded:
>
> alias char-major-226 agpgart
The new style is "alias char-major-226-* agpgart", but that should still
work in 2.6.2-rc1.
> With 2.6 and the same setup, that module is loaded. But as agpgart backend is
> now split, I need to load also intel-agp.ko. I read manuals, and corrected my
> modprobe.conf this way:
>
> install agpgart /sbin/modprobe intel-agp; /sbin/modprobe --ignore-install agpgart;
Yes. intel-agp presumably depends on agpgart? If so,
(1) You can just alias char-major-226 intel-agp
(2) There was a bug some older module-init-tools versions, have you tried
3.0-pre7?
Thanks!
Rusty.
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
^ permalink raw reply
* Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
From: Rusty Russell @ 2004-01-26 5:50 UTC (permalink / raw)
To: Greg KH; +Cc: torvalds, stern, linux-kernel, mochel
In-Reply-To: <20040123181106.GD23169@kroah.com>
On Fri, 23 Jan 2004 10:11:06 -0800
Greg KH <greg@kroah.com> wrote:
> On Fri, Jan 23, 2004 at 09:42:09AM -0800, Linus Torvalds wrote:
> >
> >
> > On Fri, 23 Jan 2004, Alan Stern wrote:
> > >
> > > Since I haven't seen any progress towards implementing the
> > > class_device_unregister_wait() and platform_device_unregister_wait()
> > > functions, here is my attempt.
> >
> > So why would this not deadlock?
>
> It will deadlock if the user does something braindead like:
> rmmod foo < /sys/class/foo_class/foo1/file
Um, if module foo exports a class, then why doesn't opening the class file
bump the owner count so the above will fail?
If you want to safely remove parts of the kernel, you have to maintain
reference counts. At least with any sane scheme I've seen.
I know, I should go read the code...
Rusty.
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
^ permalink raw reply
* Re: Linux 2.4.25-pre7
From: Rusty Russell @ 2004-01-26 5:54 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.58L.0401231652020.19820@logos.cnet>
On Fri, 23 Jan 2004 16:58:24 -0200 (BRST)
Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> Here goes -pre number 7 of 2.4.25 series.
Any chance of the forward-compatible module_param patch?
Name: 2.4 module_param Forward Compatibility Macros
Author: Rusty Russell
Status: Tested on 2.5.24-pre6
Version: 2.4
D: Simple uses of module_param() (implemented in 2.6) can be mapped
D: onto the old MODULE_PARM macros.
D:
D: New code should use module_param() because:
D: 1) Types are checked,
D: 2) Existence of parameters are checked,
D: 3) Customized types are possible [1]
D: 4) Customized set/get routines are possible [1]
D: 5) Parameters appear as boot params with prefix "<modname>." [1]
D: 6) Optional viewing and control through sysfs [2]
D:
D: [1] Not for 2.4 compatibility macros
D: [2] Not in 2.6.1 or 2.4, and only if third arg non-zero.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .25425-linux-2.4.25-pre6/include/linux/moduleparam.h .25425-linux-2.4.25-pre6.updated/include/linux/moduleparam.h
--- .25425-linux-2.4.25-pre6/include/linux/moduleparam.h 1970-01-01 10:00:00.000000000 +1000
+++ .25425-linux-2.4.25-pre6.updated/include/linux/moduleparam.h 2004-01-21 14:24:41.000000000 +1100
@@ -0,0 +1,25 @@
+#ifndef _LINUX_MODULE_PARAMS_H
+#define _LINUX_MODULE_PARAMS_H
+/* Macros for (very simple) module parameter compatibility with 2.6. */
+#include <linux/module.h>
+
+/* type is byte, short, ushort, int, uint, long, ulong, bool. (2.6
+ has more, but they are not supported). perm is permissions when
+ it appears in sysfs: 0 means doens't appear, 0444 means read-only
+ by everyone, 0644 means changable dynamically by root, etc. name
+ must be in scope (unlike MODULE_PARM).
+*/
+#define module_param(name, type, perm) \
+ static inline void *__check_existence_##name(void) { return &name; } \
+ MODULE_PARM(name, _MODULE_PARM_STRING_ ## type)
+
+#define _MODULE_PARM_STRING_byte "b"
+#define _MODULE_PARM_STRING_short "h"
+#define _MODULE_PARM_STRING_ushort "h"
+#define _MODULE_PARM_STRING_int "i"
+#define _MODULE_PARM_STRING_uint "i"
+#define _MODULE_PARM_STRING_long "l"
+#define _MODULE_PARM_STRING_ulong "l"
+#define _MODULE_PARM_STRING_bool "i"
+
+#endif /* _LINUX_MODULE_PARAM_TYPES_H */
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Andi Kleen @ 2004-01-26 6:09 UTC (permalink / raw)
To: Andrew Morton
Cc: John Stoffel, ak, Valdis.Kletnieks, bunk, cova, eric,
linux-kernel
In-Reply-To: <20040125220027.30e8cdf3.akpm@osdl.org>
On Sun, Jan 25, 2004 at 10:00:27PM -0800, Andrew Morton wrote:
> "John Stoffel" <stoffel@lucent.com> wrote:
> >
> > Sure, the darn thing wouldn't boot, it kept Oopsing with the
> > test_wp_bit oops (that I just posted more details about).
>
> Does this fix the test_wp_bit oops?
He apparently doesn't have an test_wp_bit oops, but just an hang
very early (after mem_init according to early printk)
-Andi
^ permalink raw reply
* Your prescriptio@n delivered to your house by tomorrow!
From: Stacy G. Gilbert @ 2004-01-26 6:14 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: Type: text/html, Size: 154 bytes --]
^ permalink raw reply
* Re: Request for new maintainer
From: David S. Miller @ 2004-01-26 6:06 UTC (permalink / raw)
To: bj0rn; +Cc: linux-kernel, linux-net
In-Reply-To: <20040126020835.GA9076@blox.se>
From: Björn Ekwall <bj0rn@blox.se>
Date: Mon, 26 Jan 2004 03:08:35 +0100
Lastly, I include a patch that updates my contact info.
I don't even know who to send the patch to -- that's how
out of touch I am ;-)
I'll apply this, send off another one if someone decides
to take over the drivers.
Thanks.
^ permalink raw reply
* Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
From: Valdis.Kletnieks @ 2004-01-26 6:25 UTC (permalink / raw)
To: Steve Youngs; +Cc: Linux Kernel List
In-Reply-To: <microsoft-free.87d697s18l.fsf@eicq.dnsalias.org>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
On Mon, 26 Jan 2004 15:55:06 +1000, Steve Youngs <sryoungs@bigpond.net.au> said:
> Because the 2nd user is still using the module so its in-use bit
> should still be set. Remember that when the module was first loaded
> it registered a function with the kernel for testing whether the
> module is in use.
Anybody who's ever been in a bathroom stall and somebody turned off the
lights on their way out will intuitively understand why you need a reference
count and not an in-use bit,
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.