* Re: [parisc-linux] Unaligned access failures with apt-get on SMP K460.
From: John David Anglin @ 2002-06-17 2:31 UTC (permalink / raw)
To: John David Anglin; +Cc: rbradetich, parisc-linux, richard_hirst
In-Reply-To: <200206170059.g5H0xw9a010945@hiauly1.hia.nrc.ca>
> > The instruction causing the unaligned trap is:
> > 0x4005e47c <_ZN11DynamicMMap8AllocateEm+112>: stw r21,8(sr0,r3)
> >
> > As you can see from r3 (403ce08c) in the register dump is aligned on a
> > 4-byte boundry. So the question is why is this trap being executed?
>
> Maybe the message is misleading. It looks as if the insn may be trying
> to write to readonly memory based of the value of r3.
Sorry, this is wrong. Was _ZN11DynamicMMap8AllocateEm compiled with
gcc-3.2? It looks as if C++ exceptions may be involved. This only
has a chance of working with 3.2. I suspect that an exception handler
is involved because r20 is not valid across calls and r20/r21 are
used in C++ exceptions. The call looks to be a millicode call which
might be part of the problem.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply
* MMC Support on MTD?
From: Jason Chan @ 2002-06-17 2:10 UTC (permalink / raw)
To: linux-mtd
Hi,
Any one have done the MMC driver on MTD layer? Or, any plan is doing
that?
--
Best Regards,
Jason Chan
Emsoft Ltd.
^ permalink raw reply
* Re: [linux-lvm] Re: Bug#150005: LVM does not fscking work at all
From: Patrick Caulfield @ 2002-06-17 1:58 UTC (permalink / raw)
To: linux-lvm; +Cc: Juhapekka Tolvanen
In-Reply-To: <20020617014818.A11995@verso.st.jyu.fi>
On Mon, Jun 17, 2002 at 01:48:18AM +0300, Juhapekka Tolvanen wrote:
>
> On Sat, 15 Jun 2002, +15:20:46 EEST (UTC +0300),
> Patrick Caulfield <patrick@debian.org> pressed some keys:
>
> > On Sat, Jun 15, 2002 at 03:00:26PM +0300, Juhapekka Tolvanen wrote:
>
> > > Maybe I should create a brand new .config with a little help from those
> > > aforementioned screenshots. And after that I should always use that
> > > "make oldconfig".
>
> > That might be a good thing to do. Make sure you do a "make mrproper"
> > first to really clean out the source tree.
>
> > copying a .config and doing "make oldconfig" is what I do most of the
> > time but sometimes you do need to do mrproper.
>
> It still does not fscking work! I did this:
>
> I took fresh sources of kernel 2.4.18 and unpacked them. Then I
> installed these patches:
>
> patch-2.4.19-pre10
> patch-2.4.19-pre10-ac2
> preempt-kernel-rml-2.4.19-pre10-ac2-1.patch
That /proc/devices is *still* wrong - until there's a resonable set of devices
in there LVM hasn't ahope of working. Take out all the patches and try a
"normal" kernel.
...oh, and please stop spamming everyone with your problem. It's neither an LVM
kernel nor a LVM userspace issue - simply that your kernel builds are broken.
patrick
^ permalink raw reply
* fyi: Procedure to gain physical access Toshiba 1605cds Harddisk
From: Mr. James W. Laferriere @ 2002-06-17 1:43 UTC (permalink / raw)
To: linux-laptop
Hello All , Mr. Eddie Sparks <streetdoc@ioa.com> sent along his
findings on how to break into the toshiba without breaking it ;-)
I have -one- correction to make to it . Hth , JimL
Turn the laptop over and search for three holes marked with a 'K' and
remove these three screws.
Then ...
---------- Forwarded message ----------
Date: Thu, 15 Nov 2001 01:32:23 -0500
From: Eddie Sparks <streetdoc@ioa.com>
To: babydr@baby-dragons.com
Subject: Procedure to gain physical access Toshiba 1605cds Harddisk ?
Below the display, there is panel where all the little LED's are located
indicating power on, Hard drive, etc.
You must use a fine small screwdrive and detatch or remove this small
panel which will reveal the hinges for the display.
Once this is removed, you will see 4 screws holding the keyboard in
place. Remove those screws and slide the keyboard toward the
display and it will come up. The hard drive is just below it. Two
screws hold the hard drive bracket in place. Remove those screws
and the hard drive will lift up and un plug. I had the same problem
trying to find mine and lucked up on it before I destroyed my case.
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
^ permalink raw reply
* [garloff@suse.de: Re: [linux-usb-devel] Re: /proc/scsi/map]
From: Kurt Garloff @ 2002-06-17 1:24 UTC (permalink / raw)
To: Oliver Neukum
Cc: dougg, Linux SCSI list, Linux kernel list, James Bottomley,
David Brownell, Andries.Brouwer, sancho, linux-usb-devel,
linux1394-devel
[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]
Hi,
forgot to Cc: the other recipients.
I did not want to turn this into a private discussion.
----- Forwarded message from Kurt Garloff <garloff@suse.de> -----
Date: Mon, 17 Jun 2002 02:46:24 +0200
From: Kurt Garloff <garloff@suse.de>
To: James Bottomley <James.Bottomley@steeleye.com>
Subject: Re: [linux-usb-devel] Re: /proc/scsi/map
In-Reply-To: <200206162314.g5GNEYf03058@localhost.localdomain>
User-Agent: Mutt/1.4i
X-Operating-System: Linux 2.4.16-schedJ2 i686
X-PGP-Info: on http://www.garloff.de/kurt/mykeys.pgp
X-PGP-Key: 1024D/1C98774E, 1024R/CEFC9215
Organization: TU/e(NL), SuSE(DE)
Hi,
On Sun, Jun 16, 2002 at 06:14:33PM -0500, James Bottomley wrote:
> oliver@neukum.name said:
> > But the drivers already know, or would have to be taught to know about
> > it. Somewhence that information has to come. You cannot avoid that
> > effort.
>
> Not necessarily: consider the SCSI WWN, which is supported by most modern SCSI
> devices. The driver never probes for or asks for this. Nowhere in the
> current SCSI code do we ask for this. However user level commands (like
> sg_inq) can formulate the 0x83 page inquiry to get this and return the output.
> This works today with the current driver.
This may work for your disks. You just can't open the device node for a
tape, if there is no medium inserted. If you know the mapping between
to a sg device you can use it.
That's the second piece of information that /proc/scsi/map provides.
The first piece is that the kernel tells kernel tells you the way it is
attached by reporting CBTU, which is a good identifier for good old parallel
SCSI that most of our SCSI code still is assuming.
That will change one day ...
Regards,
--
Kurt Garloff <kurt@garloff.de> [Eindhoven, NL]
Physics: Plasma simulations <K.Garloff@TUE.NL> [TU Eindhoven, NL]
Linux: SCSI, Security <garloff@suse.de> [SuSE Nuernberg, DE]
(See mail header or public key servers for PGP2 and GPG public keys.)
----- End forwarded message -----
--
Kurt Garloff <kurt@garloff.de> [Eindhoven, NL]
Physics: Plasma simulations <K.Garloff@TUE.NL> [TU Eindhoven, NL]
Linux: SCSI, Security <garloff@suse.de> [SuSE Nuernberg, DE]
(See mail header or public key servers for PGP2 and GPG public keys.)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Initcall depends
From: Kai Germaschewski @ 2002-06-17 1:17 UTC (permalink / raw)
To: Rusty Russell; +Cc: torvalds, linux-kernel
In-Reply-To: <E17JkO6-0000nW-00@wagner.rustcorp.com.au>
On Mon, 17 Jun 2002, Rusty Russell wrote:
> Linus, please apply (thanks to Peter Moulder for script tweaks).
>
> Lack of response clearly means everyone thinks this is a brilliant
> idea. They're right 8)
>
> Name: initcall depends
> Author: Rusty Russell, Peter Moulder
> Status: Tested in 2.5.21
>
> D: Introduces initcall(function, name [, dependencies ]). Dependencies
> D: are: init_after(name), init_before(name) and init_as_part_of(name).
> D: Replaces all the core_initcall, subsys_initcall etc, with three
> D: more general systems: "mm_initcalls", "bus_initcalls" and
> D: "driver_initcalls", which the other initcall define their orders in
> D: terms of. The old __initcall is supported, and link order still
> D: controls their invocation order (after driver_initcalls are
> D: finished).
As you're taking the effort of running some code to figure out the right
ordering anyway, have you considered using the the information which is
already there today, for all code which can be compiled modular.
For example, say I have the driver for the Fritz!PCI ISDN card. It depends
on the protocol driver for passive cards (hisax) being already
initialized, and hisax depends on the ISDN layer already being
initialized.
If these three units are compiled modular, the right init order will be
enforced by the fact that I can only load isdn.o, then hisax.o, then
hisax_fcpcipnp.o in that order. That's because hisax.o needs
register_isdn() which is exported by isdn.o and hisax_fcpcipnp.o needs
register_hisax() which is exported by hisax.o.
And there's even a program which figures out the right order, that's
modprobe/depmod.
That doesn't help for all the early internal init cases, but for the huge
fraction of modularized code, the info is there, though not taken
advantage of.
--Kai
^ permalink raw reply
* Re: [linux-lvm] Re: Bug#150005: LVM does not fscking work at all
From: Luca Berra @ 2002-06-17 1:06 UTC (permalink / raw)
To: Linux-LVM
In-Reply-To: <20020617014818.A11995@verso.st.jyu.fi>
On Mon, Jun 17, 2002 at 01:48:18AM +0300, Juhapekka Tolvanen wrote:
> This is really really weird! What should I do? Shall I post you that
> latest .config ?
yes please,
also try applying lvm patches from www.sistina.com and see if it changes something
L.
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
^ permalink raw reply
* Re: [parisc-linux] Unaligned access failures with apt-get on SMP K460.
From: John David Anglin @ 2002-06-17 0:59 UTC (permalink / raw)
To: Ryan Bradetich; +Cc: parisc-linux, richard_hirst
In-Reply-To: <1024273345.27050.26.camel@beavis>
> The instruction causing the unaligned trap is:
> 0x4005e47c <_ZN11DynamicMMap8AllocateEm+112>: stw r21,8(sr0,r3)
>
> As you can see from r3 (403ce08c) in the register dump is aligned on a
> 4-byte boundry. So the question is why is this trap being executed?
Maybe the message is misleading. It looks as if the insn may be trying
to write to readonly memory based of the value of r3.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply
* Re: Re: [PATCH CFT] tons of logging patches
From: Chris Mason @ 2002-06-17 0:47 UTC (permalink / raw)
To: Manuel Krause; +Cc: reiserfs-list
In-Reply-To: <3D07CBE7.5080701@mb.tu-ilmenau.de>
On Wed, 2002-06-12 at 18:32, Manuel Krause wrote:
> On 06/06/2002 02:09 AM, Chris Mason wrote:
> > Ok, ftp.suse.com/pub/people/mason/patches/data-logging has my latest
> > updates, which have more optimizations for many threads all doing
> > synchronous transactions.
> >
> > -chris
> >
>
> Mmh. I recompiled with the new one when it appeared on the server and
> kept the kernel append line with the obvious problem not to be able to
> easily reboot to my ext2 maintenance partition.
Hmmm, I might have found it, but this isn't a new bug to the 07 patch.
Have you been able to reproduce, or have you fallen back to the older
patches?
-chris
^ permalink raw reply
* recovery of software raid0 - continued
From: Maxwell Bottiger @ 2002-06-17 0:47 UTC (permalink / raw)
To: linux-raid
The attempt to recover my missing raid arrays continues...
I have 3 arrays. md0 is composed of sdd1 and sde1, md1 is composed of
sdd2 and sde2 and md2 is composed of sdd3 and sde3. md0 is mounted
under /usr, md1 _should_ be mounted under /home and md2 _should_ mounted
/mnt/shared.
The problem I have right now is that md1 says that it is composed of
sdd2 and sde2, however it is not the right size. The same is true of
md2. It looks like the data and size of the two arrays have been
reversed, even though they say the are composed of the right physical
partitions. Everything on /home looks fine, but /mnt/shared is empty
save the lost+found directory.
My questions are, first, what is wrong with the RAID mapping, and
second, is it possible that my data in /mnt/shared (aka md2) is still in
place?
^ permalink raw reply
* <<仪器快讯>>（特刊）
From: =?ISO-8859-1?Q?=D2=C7=C6=F7=D0=C5=CF=A2=CD=F8 @ 2002-06-17 0:32 UTC (permalink / raw)
To: linux-kernel
============================================================
ÒÇÆ÷ÐÅÏ¢Íø(http://www.instrument.com.cn)
ÒÇÆ÷ÀàרҵÍøÕ¾£¬ÒÇÆ÷³§É̺ÍÓû§µÄÍøÉϼÒÔ°
±¾ÍøÓɱ±¾©ÒÇÐÅÍøͨ¿Æ¼¼ÓÐÏÞ¹«Ë¾ºÍÖйú·ÖÎö²âÊÔлṲͬ½¨Éè
============================================================
±¾ÆÚ¡¶ÒÇÆ÷¿ìѶ¡·¶©ÔÄÊýΪ 18104 ·Ý
============================================================
*********************************************************************
£½£½£½¡¶ÒÇÆ÷¿ìѶ¡·£¨ÌØ¿¯£©£½£½£½
ÒÇÆ÷ÐÅÏ¢Íø·¢ÐУº2002Äê6ÔÂ17ÈÕ
*********************************************************************
ÒÇÆ÷ÐÅÏ¢Íø
http://www.instrument.com.cn
Ç°¶Îʱ¼ä£¬¸ù¾ÝÓû§µÄ·µÀ¡Òâ¼û£¬<<ÒÇÆ÷ÐÅÏ¢Íø>>ºÍ<<ÍøÉÏÒÇÆ÷Õ¹>>½øÐÐÁËÀ¸Ä¿µ÷Õû£¬Ä¿Ç°À¸Ä¿µ÷ÕûÒѾ½áÊø£¬Í¬Ê±ÎÒÃǶԴóÁ¿À¸Ä¿½øÐÐÁ˸İ棬ÒÔ±ã¸üºÃµØΪÄú·þÎñ¡£
ÓÉÓÚÀ¸Ä¿µ÷Õûºó£¬ºÜ¶àÈ˶ÔаæʽÀ¸Ä¿µÄ¾ßÌåλÖò»ÊǺÜÊìϤ£¬±¾ÆÚ<<ÒÇÆ÷¿ìѶ>>µÄÄ¿µÄÊÇÏò´ó¼Ò½éÉÜһϵ÷Õûºó¸÷À¸Ä¿µÄ¾ßÌåλÖã¬ÒÔ±ãÄú¼°Ê±ÕÒµ½ÄúËùÓõÄÐÅÏ¢¡£
£¨ÇëÁôÒâ±¾ÆÚºóÃæµÄÕÐƸÐÅÏ¢£©
<<ÒÇÆ÷ÐÅÏ¢Íø>>µÄÀ¸Ä¿ÉèÖÃÇé¿ö£º
http://www.instrument.com.cn
[×îб¨µÀ]
http://www.instrument.com.cn/category.asp?cate=1
[ÍøÉÏÒÇÆ÷Õ¹]
http://www.instrument.com.cn/show/
[³§ÉÌÁбí]
http://www.instrument.com.cn/list/ShowList.asp
[²âÊÔÖÐÐÄ]
http://www.instrument.com.cn/testcenter/testcenter.asp
[ÒÇÆ÷½²×ù]
http://www.instrument.com.cn/science/lecture/lecture.asp
[רҵÆÚ¿¯]
http://www.instrument.com.cn/journal/index.asp
[Êг¡·ÖÎö]
http://www.instrument.com.cn/market/index.asp
[Õ¹»áÐÅÏ¢]
http://www.instrument.com.cn/exhibition/exhibition.asp
[ר¼Ò×Éѯ]
http://www.instrument.com.cn/science/specialist/consult.asp
[ÒÇÆ÷ÂÛ̳]
http://www.instrument.com.cn/bbs/
[Õ¹É̶¯Ì¬]
http://www.instrument.com.cn/show/NewsList.asp
[Ó¦ÓÃÎÄÕÂ]
http://www.instrument.com.cn/science/paper/showpaper.asp
<<ÍøÉÏÒÇÆ÷Õ¹>>µÄÀ¸Ä¿ÉèÖÃÇé¿ö£º
http://www.instrument.com.cn/show/
[Õ¹ÉÌÃû¼]
http://www.instrument.com.cn/show/ShowList.asp
[²ÎÕ¹ÒÇÆ÷]
http://www.instrument.com.cn/show/ShowNameList.asp
[¼¼ÊõÎÄÕÂ]
http://www.instrument.com.cn/science/paper/showpaper.asp
[ÒÇÆ÷ÂÛ̳]
http://www.instrument.com.cn/bbs/
[Çó¹ºÐÅÏ¢]
http://www.instrument.com.cn/demand/demand.asp
[ÕбêÐÅÏ¢]
http://www.instrument.com.cn/category.asp?cate=2
[²ÎÕ¹É̶¯Ì¬]
http://www.instrument.com.cn/show/NewsList.asp
[ʵÓÃ×ÊÁÏ]
http://www.instrument.com.cn/show/serve/
[ÒÇÆ÷Ѳչ]
http://www.instrument.com.cn/show/
Èç¹ûÄúÏëÍ˶©±¾Óʼþ£¬Çëµ½£º
http://www.instrument.com.cn
ÕÐƸÐÅÏ¢£º
¸ù¾ÝÒµÎñ·¢Õ¹ÐèÒª£¬±±¾©ÒÇÐÅÍøͨ¿Æ¼¼ÓÐÏÞ¹«Ë¾£¨ÒÇÆ÷ÐÅÏ¢Íø£©Êг¡²¿ÏÖÕÐƸÊг¡ÏúÊÛÈËÔ±Ò»Ãû£¬ÒªÇó£º
1. ¾ßÓдóרÒÔÉÏÎÄ»¯£¨×îºÃ¾ßÓб±¾©Êл§¿Ú£©£¬Ó¢ÓïËļ¶ÒÔÉÏ
2. ¾ßÓзÖÎö»¯Ñ§»òÐÅÏ¢¹ÜÀíѧµÄ֪ʶ±³¾°£¬¶Ô»¥ÁªÍøÓÐÐËȤ
3. ¾ßÓÐÊг¡ÏúÊÛ¾Ñé
4. ¾ßÓÐÍŶӺÏ×÷¾«Éñ
5. À´ÐÅÇë×¢Ã÷н×ÊÒªÇó
ÓÐÒâÕßÇ뽫¼òÀú·¢EmailÖÁ£ºinfo@instrument.com.cn
»ò·¢´«ÕæÖÁ£º010£68432939
---------------------------------------------------------------
ÈôÄúÏëÍ˶©±¾Óʼþ£¬Çëµ½http://www.instrument.com.cn£¬ÌîдÄúµÄemail²¢°´Í˶©°´Å¥È·ÈÏ
=====================ÒÇÆ÷ÐÅÏ¢ÍøÁªÏµ·½·¨=====================
ͨÐŵØÖ·£º±±¾©Êк£µíÇøÎ÷Èý»·±±Â·27ºÅ±±¿Æ´óÏÃÒ»²ã Ìƺ£Ï¼ ŮʿÊÕ
ÓÊÕþ±àÂ룺100089
µç»°/´«Õ棺010-68432936/ 68432939
ÍøÖ·:http://www.instrument.com.cn
Email: info@instrument.com.cn
^ permalink raw reply
* Re: Re: [PATCH CFT] tons of logging patches
From: Manuel Krause @ 2002-06-17 0:31 UTC (permalink / raw)
To: Chris Mason; +Cc: reiserfs-list
In-Reply-To: <1024274859.11086.68.camel@tiny>
On 06/17/2002 02:47 AM, Chris Mason wrote:
> On Wed, 2002-06-12 at 18:32, Manuel Krause wrote:
>
>>On 06/06/2002 02:09 AM, Chris Mason wrote:
>>
>>>Ok, ftp.suse.com/pub/people/mason/patches/data-logging has my latest
>>>updates, which have more optimizations for many threads all doing
>>>synchronous transactions.
>>>
>>>-chris
>>>
>>
>>Mmh. I recompiled with the new one when it appeared on the server and
>>kept the kernel append line with the obvious problem not to be able to
>>easily reboot to my ext2 maintenance partition.
>
>
> Hmmm, I might have found it, but this isn't a new bug to the 07 patch.
> Have you been able to reproduce, or have you fallen back to the older
> patches?
>
You mean 03-beta-data-logging-7.diff.gz when saying "07 patch"? Then I
didn't go back according to my disk content.
When I boot up I read on screen and in boot.msg:
...
EXT2-fs: Unrecognized mount option data
reiserfs: using ordered data mode
reiserfs: found format "3.6" with standard journal
reiserfs: checking transaction log (ide0(3,7)) for (ide0(3,7))
(...)
Using r5 hash to sort names
...
Addon is: I use the ReiserFS pending patches that apply as I mentionned
previously(?).
No, it looks o.k. here.
> -chris
>
Manuel
^ permalink raw reply
* [PATCH] Initcall depends
From: Rusty Russell @ 2002-06-17 0:28 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Linus, please apply (thanks to Peter Moulder for script tweaks).
Lack of response clearly means everyone thinks this is a brilliant
idea. They're right 8)
Name: initcall depends
Author: Rusty Russell, Peter Moulder
Status: Tested in 2.5.21
D: Introduces initcall(function, name [, dependencies ]). Dependencies
D: are: init_after(name), init_before(name) and init_as_part_of(name).
D: Replaces all the core_initcall, subsys_initcall etc, with three
D: more general systems: "mm_initcalls", "bus_initcalls" and
D: "driver_initcalls", which the other initcall define their orders in
D: terms of. The old __initcall is supported, and link order still
D: controls their invocation order (after driver_initcalls are
D: finished).
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/include/linux/init.h working-2.5.21-initorder/include/linux/init.h
--- linux-2.5.21/include/linux/init.h Mon Jun 10 16:03:55 2002
+++ working-2.5.21-initorder/include/linux/init.h Sun Jun 16 05:09:43 2002
@@ -1,7 +1,12 @@
#ifndef _LINUX_INIT_H
#define _LINUX_INIT_H
+/* Hacked on by just about everyone. Explicit ordering work by:
+ * Rusty Russell (C) 2002 IBM Corporation */
+
+/* Change this file, make sure you don't break scripts/build-initcalls */
#include <linux/config.h>
+#include <linux/stringify.h>
/* These macros are used to mark some functions or
* initialized data (doesn't apply to uninitialized data)
@@ -48,29 +53,46 @@
typedef int (*initcall_t)(void);
typedef void (*exitcall_t)(void);
-extern initcall_t __initcall_start, __initcall_end;
+#define INITCALL_MAX_NAMELEN 64
+#define INITCALL_MAX_DEPS 3
-/* initcalls are now grouped by functionality into separate
- * subsections. Ordering inside the subsections is determined
- * by link order.
- * For backwards compatability, initcall() puts the call in
- * the device init subsection.
- */
+/* Ensure it's initialized after x */
+#define init_after(x) { .follows = __stringify(x) "-end" }
-#define __define_initcall(level,fn) \
- static initcall_t __initcall_##fn __attribute__ ((unused,__section__ (".initcall" level ".init"))) = fn
+/* Ensure it's initialized before x */
+#define init_before(x) { .preceeds = __stringify(x) "-start" }
-#define core_initcall(fn) __define_initcall("1",fn)
-#define postcore_initcall(fn) __define_initcall("2",fn)
-#define arch_initcall(fn) __define_initcall("3",fn)
-#define subsys_initcall(fn) __define_initcall("4",fn)
-#define fs_initcall(fn) __define_initcall("5",fn)
-#define device_initcall(fn) __define_initcall("6",fn)
-#define late_initcall(fn) __define_initcall("7",fn)
+/* This is part of the x subsystem initialization */
+#define init_as_part_of(x) \
+ { .follows = __stringify(x) "-start", .preceeds = __stringify(x) "-end" }
-#define __initcall(fn) device_initcall(fn)
+/* Example usage:
+ initcall(ppc_extras_init,
+ init_after(other_device_init),
+ init_as_part_of(device_initcalls));
+ Do not use a "_initcalls" name except for subsystems (ie. init_as_part_of).
+*/
+#define initcall(initfn,...) \
+ static inline initcall_t __init_##initfn##_test(void) \
+ { return initfn; } \
+ int __init_##initfn(void) __attribute__((alias(#initfn))); \
+ static const struct initcall_info initfn##_initcall_info \
+ __attribute__ ((__section__ (".initcalls"))) = \
+ { .name = __stringify(initfn), { __VA_ARGS__ } };
-#define __exitcall(fn) \
+struct initcall_order
+{
+ char preceeds[INITCALL_MAX_NAMELEN];
+ char follows[INITCALL_MAX_NAMELEN];
+};
+
+struct initcall_info
+{
+ char name[INITCALL_MAX_NAMELEN];
+ struct initcall_order order[INITCALL_MAX_DEPS];
+};
+
+#define __exitcall(fn) \
static exitcall_t __exitcall_##fn __exit_call = fn
/*
@@ -86,7 +108,6 @@
#define __setup(str, fn) \
static char __setup_str_##fn[] __initdata = str; \
static struct kernel_param __setup_##fn __attribute__((unused)) __initsetup = { __setup_str_##fn, fn }
-
#endif /* __ASSEMBLY__ */
/*
@@ -135,7 +156,6 @@
#define __exit
#define __initdata
#define __exitdata
-#define __initcall(fn)
/* For assembly routines */
#define __INIT
#define __FINIT
@@ -159,14 +179,7 @@
#define __setup(str,func) /* nothing */
-#define core_initcall(fn) module_init(fn)
-#define postcore_initcall(fn) module_init(fn)
-#define arch_initcall(fn) module_init(fn)
-#define subsys_initcall(fn) module_init(fn)
-#define fs_initcall(fn) module_init(fn)
-#define device_initcall(fn) module_init(fn)
-#define late_initcall(fn) module_init(fn)
-
+#define initcall(initfn,initname,...) module_init(initfn)
#endif
/* Data marked not to be saved by software_suspend() */
@@ -185,5 +198,17 @@
#define __devexitdata __exitdata
#define __devexit_p(x) 0
#endif
+
+/* This many levels of indirection really required */
+#define ___CAT3(a,b,c) a##_##b##_##c
+#define __CAT3(a,b,c) ___CAT3(a,b,c)
+#define __FAKENAME(fn) __CAT3(KBUILD_BASENAME,fn,__LINE__)
+
+#define ___initcall(a,...) initcall(a, __VA_ARGS__)
+
+/* Backwards compat macro: deprecated */
+#define __initcall(fn) \
+ static int __FAKENAME(fn)(void) { return fn(); } \
+ ___initcall(__FAKENAME(fn), init_as_part_of(deprecated_initcalls))
#endif /* _LINUX_INIT_H */
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/Makefile working-2.5.21-initorder/Makefile
--- linux-2.5.21/Makefile Mon Jun 10 16:03:45 2002
+++ working-2.5.21-initorder/Makefile Sun Jun 16 05:09:43 2002
@@ -216,6 +216,7 @@
$(DRIVERS) \
$(NETWORKS) \
--end-group \
+ init/generated-initcalls.o \
-o vmlinux
# set -e makes the rule exit immediately on error
@@ -232,7 +233,10 @@
$(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
endef
-vmlinux: $(vmlinux-objs) FORCE
+init/generated-initcalls.c: $(vmlinux-objs) scripts/build-initcalls
+ sh -e scripts/build-initcalls $(OBJDUMP) $(vmlinux-objs) >$@
+
+vmlinux: $(vmlinux-objs) init/generated-initcalls.o FORCE
$(call if_changed_rule,link_vmlinux)
# The actual objects are generated when descending,
@@ -574,7 +578,7 @@
# files removed with 'make clean'
CLEAN_FILES += \
- kernel/ksyms.lst include/linux/compile.h \
+ init/generated-initcalls.c kernel/ksyms.lst include/linux/compile.h \
vmlinux System.map \
.tmp* \
drivers/char/consolemap_deftbl.c drivers/video/promcon_tbl.c \
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/alpha/kernel/pci.c working-2.5.21-initorder/arch/alpha/kernel/pci.c
--- linux-2.5.21/arch/alpha/kernel/pci.c Thu May 30 10:00:47 2002
+++ working-2.5.21-initorder/arch/alpha/kernel/pci.c Sun Jun 16 05:09:44 2002
@@ -198,7 +198,7 @@
alpha_mv.init_pci();
}
-subsys_initcall(pcibios_init);
+initcall(pcibios_init, init_as_part_of(bus_initcalls));
char * __init
pcibios_setup(char *str)
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/arm/kernel/ecard.c working-2.5.21-initorder/arch/arm/kernel/ecard.c
--- linux-2.5.21/arch/arm/kernel/ecard.c Sat May 25 14:34:35 2002
+++ working-2.5.21-initorder/arch/arm/kernel/ecard.c Sun Jun 16 05:09:44 2002
@@ -1055,7 +1055,9 @@
ecard_proc_init();
}
-subsys_initcall(ecard_init);
+initcall(ecard_init,
+ init_after(pci_registration_init),
+ init_as_part_of(bus_initcalls));
EXPORT_SYMBOL(ecard_startfind);
EXPORT_SYMBOL(ecard_find);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/arm/mach-footbridge/cats-pci.c working-2.5.21-initorder/arch/arm/mach-footbridge/cats-pci.c
--- linux-2.5.21/arch/arm/mach-footbridge/cats-pci.c Sat May 25 14:34:35 2002
+++ working-2.5.21-initorder/arch/arm/mach-footbridge/cats-pci.c Sun Jun 16 05:09:44 2002
@@ -52,4 +52,4 @@
return 0;
}
-subsys_initcall(cats_pci_init);
+initcall(cats_pci_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/arm/mach-footbridge/ebsa285-pci.c working-2.5.21-initorder/arch/arm/mach-footbridge/ebsa285-pci.c
--- linux-2.5.21/arch/arm/mach-footbridge/ebsa285-pci.c Sat May 25 14:34:35 2002
+++ working-2.5.21-initorder/arch/arm/mach-footbridge/ebsa285-pci.c Sun Jun 16 05:09:44 2002
@@ -45,4 +45,4 @@
return 0;
}
-subsys_initcall(ebsa285_init_pci);
+initcall(ebsa285_init_pci, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/arm/mach-footbridge/netwinder-pci.c working-2.5.21-initorder/arch/arm/mach-footbridge/netwinder-pci.c
--- linux-2.5.21/arch/arm/mach-footbridge/netwinder-pci.c Sat May 25 14:34:35 2002
+++ working-2.5.21-initorder/arch/arm/mach-footbridge/netwinder-pci.c Sun Jun 16 05:09:44 2002
@@ -59,4 +59,4 @@
return 0;
}
-subsys_initcall(netwinder_pci_init);
+initcall(netwinder_pci_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/arm/mach-footbridge/personal-pci.c working-2.5.21-initorder/arch/arm/mach-footbridge/personal-pci.c
--- linux-2.5.21/arch/arm/mach-footbridge/personal-pci.c Sat May 25 14:34:35 2002
+++ working-2.5.21-initorder/arch/arm/mach-footbridge/personal-pci.c Sun Jun 16 05:09:44 2002
@@ -53,4 +53,4 @@
return 0;
}
-subsys_initcall(&personal_pci_init);
+initcall(personal_pci_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/arm/mach-ftvpci/pci.c working-2.5.21-initorder/arch/arm/mach-ftvpci/pci.c
--- linux-2.5.21/arch/arm/mach-ftvpci/pci.c Sat May 25 14:34:35 2002
+++ working-2.5.21-initorder/arch/arm/mach-ftvpci/pci.c Sun Jun 16 05:09:44 2002
@@ -57,4 +57,4 @@
return 0;
}
-subsys_initcall(ftv_pci_init);
+initcall(ftv_pci_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/arm/mach-integrator/pci.c working-2.5.21-initorder/arch/arm/mach-integrator/pci.c
--- linux-2.5.21/arch/arm/mach-integrator/pci.c Sat May 25 14:34:35 2002
+++ working-2.5.21-initorder/arch/arm/mach-integrator/pci.c Sun Jun 16 05:09:44 2002
@@ -130,4 +130,4 @@
return 0;
}
-subsys_initcall(integrator_pci_init);
+initcall(integrator_pci_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/arm/mach-iop310/iq80310-pci.c working-2.5.21-initorder/arch/arm/mach-iop310/iq80310-pci.c
--- linux-2.5.21/arch/arm/mach-iop310/iq80310-pci.c Sat May 25 14:34:36 2002
+++ working-2.5.21-initorder/arch/arm/mach-iop310/iq80310-pci.c Sun Jun 16 05:09:44 2002
@@ -156,4 +156,4 @@
return 0;
}
-subsys_initcall(iq80310_pci_init);
+initcall(iq80310_pci_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/arm/mach-shark/pci.c working-2.5.21-initorder/arch/arm/mach-shark/pci.c
--- linux-2.5.21/arch/arm/mach-shark/pci.c Sat May 25 14:34:36 2002
+++ working-2.5.21-initorder/arch/arm/mach-shark/pci.c Sun Jun 16 05:09:44 2002
@@ -39,4 +39,4 @@
return 0;
}
-subsys_initcall(shark_pci_init);
+initcall(shark_pci_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/i386/kernel/mca.c working-2.5.21-initorder/arch/i386/kernel/mca.c
--- linux-2.5.21/arch/i386/kernel/mca.c Wed Feb 20 17:55:58 2002
+++ working-2.5.21-initorder/arch/i386/kernel/mca.c Sun Jun 16 05:09:44 2002
@@ -311,7 +311,7 @@
#endif
}
-subsys_initcall(mca_init);
+initcall(mca_init, init_as_part_of(bus_initcalls));
/*--------------------------------------------------------------------*/
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/i386/pci/acpi.c working-2.5.21-initorder/arch/i386/pci/acpi.c
--- linux-2.5.21/arch/i386/pci/acpi.c Mon Jun 10 16:03:47 2002
+++ working-2.5.21-initorder/arch/i386/pci/acpi.c Sun Jun 16 05:09:44 2002
@@ -22,4 +22,4 @@
return 0;
}
-subsys_initcall(pci_acpi_init);
+initcall(pci_acpi_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/i386/pci/common.c working-2.5.21-initorder/arch/i386/pci/common.c
--- linux-2.5.21/arch/i386/pci/common.c Mon Jun 10 16:03:47 2002
+++ working-2.5.21-initorder/arch/i386/pci/common.c Sun Jun 16 05:09:44 2002
@@ -139,7 +139,7 @@
return 0;
}
-subsys_initcall(pcibios_init);
+initcall(pcibios_init, init_as_part_of(bus_initcalls));
char * __devinit pcibios_setup(char *str)
{
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/i386/pci/direct.c working-2.5.21-initorder/arch/i386/pci/direct.c
--- linux-2.5.21/arch/i386/pci/direct.c Mon Jun 10 16:03:47 2002
+++ working-2.5.21-initorder/arch/i386/pci/direct.c Sun Jun 16 05:09:44 2002
@@ -364,4 +364,6 @@
return 0;
}
-arch_initcall(pci_direct_init);
+initcall(pci_direct_init,
+ init_as_part_of(bus_initcalls),
+ init_after(pci_pcbios_init)); /* FIXME: Does it matter? --RR */
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/i386/pci/irq.c working-2.5.21-initorder/arch/i386/pci/irq.c
--- linux-2.5.21/arch/i386/pci/irq.c Mon Jun 3 12:21:20 2002
+++ working-2.5.21-initorder/arch/i386/pci/irq.c Sun Jun 16 05:09:44 2002
@@ -717,7 +717,9 @@
return 0;
}
-subsys_initcall(pcibios_irq_init);
+initcall(pcibios_irq_init,
+ init_after(pcibios_init),
+ init_before(device_initcalls));
void __init pcibios_fixup_irqs(void)
{
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/i386/pci/legacy.c working-2.5.21-initorder/arch/i386/pci/legacy.c
--- linux-2.5.21/arch/i386/pci/legacy.c Mon Jun 10 16:03:47 2002
+++ working-2.5.21-initorder/arch/i386/pci/legacy.c Sun Jun 16 05:09:44 2002
@@ -54,4 +54,6 @@
return 0;
}
-subsys_initcall(pci_legacy_init);
+initcall(pci_legacy_init,
+ init_after(pcibios_init),
+ init_before(device_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/i386/pci/numa.c working-2.5.21-initorder/arch/i386/pci/numa.c
--- linux-2.5.21/arch/i386/pci/numa.c Mon Jun 10 16:03:47 2002
+++ working-2.5.21-initorder/arch/i386/pci/numa.c Sun Jun 16 05:09:44 2002
@@ -120,4 +120,6 @@
return 0;
}
-subsys_initcall(pci_numa_init);
+initcall(pci_numa_init,
+ init_after(pcibios_init),
+ init_before(device_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/i386/pci/pcbios.c working-2.5.21-initorder/arch/i386/pci/pcbios.c
--- linux-2.5.21/arch/i386/pci/pcbios.c Mon Jun 10 16:03:47 2002
+++ working-2.5.21-initorder/arch/i386/pci/pcbios.c Sun Jun 16 05:09:44 2002
@@ -557,4 +557,4 @@
return 0;
}
-arch_initcall(pci_pcbios_init);
+initcall(pci_pcbios_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/ia64/hp/sim/simscsi.c working-2.5.21-initorder/arch/ia64/hp/sim/simscsi.c
--- linux-2.5.21/arch/ia64/hp/sim/simscsi.c Tue Apr 23 11:39:32 2002
+++ working-2.5.21-initorder/arch/ia64/hp/sim/simscsi.c Sun Jun 16 05:09:44 2002
@@ -363,6 +363,7 @@
static Scsi_Host_Template driver_template = SIMSCSI;
-#define __initcall(fn) late_initcall(fn)
+/* FIXME: Um, really? --RR */
+#define __initcall(fn) initcall(fn, init_after(device_initcalls))
#include "../drivers/scsi/scsi_module.c"
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/ia64/kernel/pci.c working-2.5.21-initorder/arch/ia64/kernel/pci.c
--- linux-2.5.21/arch/ia64/kernel/pci.c Thu May 30 10:00:47 2002
+++ working-2.5.21-initorder/arch/ia64/kernel/pci.c Sun Jun 16 05:09:44 2002
@@ -221,7 +221,7 @@
return 0;
}
-subsys_initcall(pcibios_init);
+initcall(pcibios_init, init_as_part_of(bus_initcalls));
/*
* Called after each bus is probed, but before its children
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/ppc/kernel/pci.c working-2.5.21-initorder/arch/ppc/kernel/pci.c
--- linux-2.5.21/arch/ppc/kernel/pci.c Mon May 13 12:00:31 2002
+++ working-2.5.21-initorder/arch/ppc/kernel/pci.c Sun Jun 16 05:09:45 2002
@@ -1074,7 +1074,7 @@
return 0;
}
-subsys_initcall(pcibios_init);
+initcall(pcibios_init, init_as_part_of(bus_initcalls));
unsigned char __init
common_swizzle(struct pci_dev *dev, unsigned char *pinp)
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/ppc/kernel/setup.c working-2.5.21-initorder/arch/ppc/kernel/setup.c
--- linux-2.5.21/arch/ppc/kernel/setup.c Mon May 13 12:00:32 2002
+++ working-2.5.21-initorder/arch/ppc/kernel/setup.c Sun Jun 16 05:09:45 2002
@@ -581,7 +581,7 @@
return 0;
}
-arch_initcall(ppc_init);
+initcall(ppc_init, arch_init, init_after(core_initcalls));
/* Warning, IO base is not yet inited */
void __init setup_arch(char **cmdline_p)
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/ppc/platforms/lopec_setup.c working-2.5.21-initorder/arch/ppc/platforms/lopec_setup.c
--- linux-2.5.21/arch/ppc/platforms/lopec_setup.c Thu May 30 10:00:49 2002
+++ working-2.5.21-initorder/arch/ppc/platforms/lopec_setup.c Sun Jun 16 05:09:45 2002
@@ -235,7 +235,7 @@
return 0;
}
-device_initcall(lopec_request_io);
+initcall(lopec_request_io, init_as_part_of(device_initcalls));
static void __init
lopec_map_io(void)
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/ppc/platforms/pmac_feature.c working-2.5.21-initorder/arch/ppc/platforms/pmac_feature.c
--- linux-2.5.21/arch/ppc/platforms/pmac_feature.c Mon May 13 12:00:32 2002
+++ working-2.5.21-initorder/arch/ppc/platforms/pmac_feature.c Sun Jun 16 05:09:45 2002
@@ -2126,4 +2126,4 @@
return 0;
}
-device_initcall(pmac_feature_late_init);
+initcall(pmac_feature_late_init, init_as_part_of(device_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/ppc/platforms/pmac_setup.c working-2.5.21-initorder/arch/ppc/platforms/pmac_setup.c
--- linux-2.5.21/arch/ppc/platforms/pmac_setup.c Mon May 13 12:00:32 2002
+++ working-2.5.21-initorder/arch/ppc/platforms/pmac_setup.c Sun Jun 16 05:09:45 2002
@@ -463,7 +463,11 @@
return 0;
}
-late_initcall(pmac_late_init);
+/* Say it's after both so it doesn't break when deprecated_initcalls
+ vanishes */
+initcall(pmac_late_init,
+ init_after(device_initcalls),
+ init_after(deprecated_initcalls));
/* can't be __init - can be called whenever a disk is first accessed */
void __pmac
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/ppc/platforms/prep_setup.c working-2.5.21-initorder/arch/ppc/platforms/prep_setup.c
--- linux-2.5.21/arch/ppc/platforms/prep_setup.c Thu May 30 10:00:49 2002
+++ working-2.5.21-initorder/arch/ppc/platforms/prep_setup.c Sun Jun 16 05:09:45 2002
@@ -825,7 +825,7 @@
return 0;
}
-device_initcall(prep_request_io);
+initcall(prep_request_io, init_as_part_of(device_initcalls));
void __init
prep_init(unsigned long r3, unsigned long r4, unsigned long r5,
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/ppc64/kernel/pci.c working-2.5.21-initorder/arch/ppc64/kernel/pci.c
--- linux-2.5.21/arch/ppc64/kernel/pci.c Mon Jun 3 12:21:20 2002
+++ working-2.5.21-initorder/arch/ppc64/kernel/pci.c Sun Jun 16 05:09:45 2002
@@ -498,7 +498,7 @@
}
-subsys_initcall(pcibios_init);
+initcall(pcibios_init, init_as_part_of(bus_initcalls));
int __init
pcibios_assign_all_busses(void)
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/ppc64/kernel/setup.c working-2.5.21-initorder/arch/ppc64/kernel/setup.c
--- linux-2.5.21/arch/ppc64/kernel/setup.c Mon Jun 3 12:21:21 2002
+++ working-2.5.21-initorder/arch/ppc64/kernel/setup.c Sun Jun 16 05:09:45 2002
@@ -485,7 +485,7 @@
return 0;
}
-arch_initcall(ppc_init);
+initcall(ppc_init, arch_init, init_after(core_initcalls));
void __init ppc64_calibrate_delay(void)
{
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/arch/sparc64/kernel/pci.c working-2.5.21-initorder/arch/sparc64/kernel/pci.c
--- linux-2.5.21/arch/sparc64/kernel/pci.c Sun May 19 12:07:29 2002
+++ working-2.5.21-initorder/arch/sparc64/kernel/pci.c Sun Jun 16 05:09:45 2002
@@ -201,7 +201,7 @@
return 0;
}
-subsys_initcall(pcibios_init);
+initcall(pcibios_init, init_as_part_of(bus_initcalls));
struct pci_fixup pcibios_fixups[] = {
{ 0 }
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/acpi/bus.c working-2.5.21-initorder/drivers/acpi/bus.c
--- linux-2.5.21/drivers/acpi/bus.c Mon Jun 3 12:21:21 2002
+++ working-2.5.21-initorder/drivers/acpi/bus.c Sun Jun 16 05:09:45 2002
@@ -2190,6 +2190,7 @@
return 1;
}
-subsys_initcall(acpi_init);
+initcall(acpi_init,
+ init_as_part_of(bus_initcalls)); /* FIXME: should it be after?-- RR */
__setup("acpi=", acpi_setup);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/base/bus.c working-2.5.21-initorder/drivers/base/bus.c
--- linux-2.5.21/drivers/base/bus.c Mon Jun 10 16:03:48 2002
+++ working-2.5.21-initorder/drivers/base/bus.c Sun Jun 16 05:09:45 2002
@@ -198,13 +198,15 @@
driverfs_remove_dir(&bus->dir);
}
-static int __init bus_init(void)
+static int __init driverfs_bus_init(void)
{
/* make 'bus' driverfs directory */
return driverfs_create_dir(&bus_dir,NULL);
}
-core_initcall(bus_init);
+initcall(driverfs_bus_init,
+ init_after(driverfs_init),
+ init_before(bus_initcalls));
EXPORT_SYMBOL(bus_for_each_dev);
EXPORT_SYMBOL(bus_for_each_drv);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/base/core.c working-2.5.21-initorder/drivers/base/core.c
--- linux-2.5.21/drivers/base/core.c Mon Jun 10 16:03:48 2002
+++ working-2.5.21-initorder/drivers/base/core.c Sun Jun 16 05:09:45 2002
@@ -278,7 +278,7 @@
return device_register(&device_root);
}
-static int __init device_init(void)
+static int __init driverfs_init(void)
{
int error;
@@ -293,7 +293,7 @@
return error;
}
-core_initcall(device_init);
+initcall(driverfs_init, init_before(bus_initcalls));
EXPORT_SYMBOL(device_register);
EXPORT_SYMBOL(put_device);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/base/sys.c working-2.5.21-initorder/drivers/base/sys.c
--- linux-2.5.21/drivers/base/sys.c Mon Jun 10 16:03:48 2002
+++ working-2.5.21-initorder/drivers/base/sys.c Sun Jun 16 05:09:45 2002
@@ -44,6 +44,7 @@
return device_register(&system_bus);
}
-postcore_initcall(sys_bus_init);
+initcall(sys_bus_init, init_after(driverfs_init), init_before(bus_initcalls));
+
EXPORT_SYMBOL(register_sys_device);
EXPORT_SYMBOL(unregister_sys_device);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/dio/dio.c working-2.5.21-initorder/drivers/dio/dio.c
--- linux-2.5.21/drivers/dio/dio.c Wed Feb 20 17:56:01 2002
+++ working-2.5.21-initorder/drivers/dio/dio.c Sun Jun 16 05:09:45 2002
@@ -208,7 +208,7 @@
}
}
-subsys_initcall(dio_init);
+initcall(dio_init, init_as_part_of(bus_initcalls));
/* Bear in mind that this is called in the very early stages of initialisation
* in order to get the virtual address of the serial port for the console...
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/macintosh/mediabay.c working-2.5.21-initorder/drivers/macintosh/mediabay.c
--- linux-2.5.21/drivers/macintosh/mediabay.c Thu May 30 10:00:53 2002
+++ working-2.5.21-initorder/drivers/macintosh/mediabay.c Sun Jun 16 05:09:45 2002
@@ -834,4 +834,4 @@
return 0;
}
-device_initcall(media_bay_init);
+initcall(media_bay_init, init_as_part_of(device_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/macintosh/via-cuda.c working-2.5.21-initorder/drivers/macintosh/via-cuda.c
--- linux-2.5.21/drivers/macintosh/via-cuda.c Sun May 19 12:07:30 2002
+++ working-2.5.21-initorder/drivers/macintosh/via-cuda.c Sun Jun 16 05:09:45 2002
@@ -204,7 +204,7 @@
return 0;
}
-device_initcall(via_cuda_start);
+initcall(via_cuda_start, init_as_part_of(device_initcalls));
#ifdef CONFIG_ADB
static int
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/macintosh/via-pmu.c working-2.5.21-initorder/drivers/macintosh/via-pmu.c
--- linux-2.5.21/drivers/macintosh/via-pmu.c Sun May 19 12:07:30 2002
+++ working-2.5.21-initorder/drivers/macintosh/via-pmu.c Sun Jun 16 05:09:45 2002
@@ -440,7 +440,7 @@
return 0;
}
-arch_initcall(via_pmu_start);
+initcall(via_pmu_start, init_before(device_initcalls));
/*
* This has to be done after pci_init, which is a subsys_initcall.
@@ -498,7 +498,7 @@
return 0;
}
-device_initcall(via_pmu_dev_init);
+initcall(via_pmu_dev_init, via_pmu_init, init_after(pci_init));
static int __openfirmware
init_pmu()
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/nubus/nubus.c working-2.5.21-initorder/drivers/nubus/nubus.c
--- linux-2.5.21/drivers/nubus/nubus.c Wed Feb 20 17:56:05 2002
+++ working-2.5.21-initorder/drivers/nubus/nubus.c Sun Jun 16 05:09:45 2002
@@ -1040,4 +1040,4 @@
#endif
}
-subsys_initcall(nubus_init);
+initcall(nubus_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/pci/pci-driver.c working-2.5.21-initorder/drivers/pci/pci-driver.c
--- linux-2.5.21/drivers/pci/pci-driver.c Mon Jun 10 16:03:50 2002
+++ working-2.5.21-initorder/drivers/pci/pci-driver.c Sun Jun 16 05:09:45 2002
@@ -199,12 +199,14 @@
match: pci_bus_match,
};
-static int __init pci_driver_init(void)
+static int __init pci_registration_init(void)
{
return bus_register(&pci_bus_type);
}
-postcore_initcall(pci_driver_init);
+initcall(pci_registration_init,
+ init_before(bus_initcalls),
+ init_after(driverfs_bus_init));
EXPORT_SYMBOL(pci_match_device);
EXPORT_SYMBOL(pci_register_driver);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/pci/pci.c working-2.5.21-initorder/drivers/pci/pci.c
--- linux-2.5.21/drivers/pci/pci.c Mon May 13 12:00:36 2002
+++ working-2.5.21-initorder/drivers/pci/pci.c Sun Jun 16 05:09:45 2002
@@ -555,7 +555,7 @@
return 0;
}
-static int __devinit pci_init(void)
+static int __devinit pci_fixups(void)
{
struct pci_dev *dev;
@@ -580,7 +580,7 @@
return 1;
}
-device_initcall(pci_init);
+initcall(pci_fixups, init_after(bus_initcalls), init_before(device_initcalls));
__setup("pci=", pci_setup);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/pci/power.c working-2.5.21-initorder/drivers/pci/power.c
--- linux-2.5.21/drivers/pci/power.c Tue May 21 16:33:32 2002
+++ working-2.5.21-initorder/drivers/pci/power.c Sun Jun 16 05:09:45 2002
@@ -162,4 +162,5 @@
return 0;
}
-subsys_initcall(pci_pm_init);
+initcall(pci_pm_init,
+ init_as_part_of(bus_initcalls)); /* FIXME: should it be after?-- RR */
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/pcmcia/ds.c working-2.5.21-initorder/drivers/pcmcia/ds.c
--- linux-2.5.21/drivers/pcmcia/ds.c Mon May 13 12:00:36 2002
+++ working-2.5.21-initorder/drivers/pcmcia/ds.c Sun Jun 16 05:09:45 2002
@@ -966,7 +966,7 @@
return 0;
}
-late_initcall(init_pcmcia_ds);
+initcall(init_pcmcia_ds, init_after(device_initcalls));
#ifdef MODULE
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/pnp/isapnp.c working-2.5.21-initorder/drivers/pnp/isapnp.c
--- linux-2.5.21/drivers/pnp/isapnp.c Thu Mar 21 14:14:48 2002
+++ working-2.5.21-initorder/drivers/pnp/isapnp.c Sun Jun 16 05:09:45 2002
@@ -2393,7 +2393,7 @@
return 0;
}
-subsys_initcall(isapnp_init);
+initcall(isapnp_init, init_as_part_of(bus_initcalls));
#ifdef MODULE
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/pnp/pnpbios_core.c working-2.5.21-initorder/drivers/pnp/pnpbios_core.c
--- linux-2.5.21/drivers/pnp/pnpbios_core.c Sat May 25 14:34:46 2002
+++ working-2.5.21-initorder/drivers/pnp/pnpbios_core.c Sun Jun 16 05:09:45 2002
@@ -1218,7 +1218,7 @@
__setup("pnpbios=", pnpbios_setup);
#endif
-subsys_initcall(pnpbios_init);
+initcall(pnpbios_init, init_as_part_of(bus_initcalls));
int __init pnpbios_init(void)
{
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/sbus/sbus.c working-2.5.21-initorder/drivers/sbus/sbus.c
--- linux-2.5.21/drivers/sbus/sbus.c Mon Apr 15 11:47:28 2002
+++ working-2.5.21-initorder/drivers/sbus/sbus.c Sun Jun 16 05:09:46 2002
@@ -517,4 +517,4 @@
return 0;
}
-subsys_initcall(sbus_init);
+initcall(sbus_init, init_as_part_of(bus_initcalls));
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/tc/tc.c working-2.5.21-initorder/drivers/tc/tc.c
--- linux-2.5.21/drivers/tc/tc.c Wed Feb 20 17:56:08 2002
+++ working-2.5.21-initorder/drivers/tc/tc.c Sun Jun 16 05:09:46 2002
@@ -165,7 +165,7 @@
/*
* the main entry
*/
-void __init tc_init(void)
+void __init turbochannel_init(void)
{
int tc_clock;
int i;
@@ -236,7 +236,7 @@
}
}
-subsys_initcall(tc_init);
+initcall(turbochannel_init, init_as_part_of(bus_initcalls));
EXPORT_SYMBOL(search_tc_card);
EXPORT_SYMBOL(claim_tc_card);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/usb/core/usb.c working-2.5.21-initorder/drivers/usb/core/usb.c
--- linux-2.5.21/drivers/usb/core/usb.c Mon Jun 3 12:21:26 2002
+++ working-2.5.21-initorder/drivers/usb/core/usb.c Sun Jun 16 05:09:46 2002
@@ -1447,7 +1447,7 @@
usb_hub_cleanup();
}
-subsys_initcall(usb_init);
+initcall(usb_init, init_as_part_of(bus_initcalls));
module_exit(usb_exit);
/*
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/drivers/zorro/zorro.c working-2.5.21-initorder/drivers/zorro/zorro.c
--- linux-2.5.21/drivers/zorro/zorro.c Mon May 13 12:00:37 2002
+++ working-2.5.21-initorder/drivers/zorro/zorro.c Sun Jun 16 05:09:46 2002
@@ -172,7 +172,7 @@
return 0;
}
-subsys_initcall(zorro_init);
+initcall(zorro_init, init_as_part_of(bus_initcalls));
EXPORT_SYMBOL(zorro_find_device);
EXPORT_SYMBOL(zorro_unused_z2ram);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/init/main.c working-2.5.21-initorder/init/main.c
--- linux-2.5.21/init/main.c Mon Jun 10 16:03:56 2002
+++ working-2.5.21-initorder/init/main.c Sun Jun 16 05:09:46 2002
@@ -421,19 +421,7 @@
struct task_struct *child_reaper = &init_task;
-static void __init do_initcalls(void)
-{
- initcall_t *call;
-
- call = &__initcall_start;
- do {
- (*call)();
- call++;
- } while (call < &__initcall_end);
-
- /* Make sure there is no pending stuff from the initcall sequence */
- flush_scheduled_tasks();
-}
+extern void do_initcalls(void);
/*
* Ok, the machine is now initialized. None of the devices
@@ -485,6 +473,8 @@
start_context_thread();
do_initcalls();
+ /* Make sure there is no pending stuff from the initcall sequence */
+ flush_scheduled_tasks();
}
extern void prepare_namespace(void);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/kernel/exec_domain.c working-2.5.21-initorder/kernel/exec_domain.c
--- linux-2.5.21/kernel/exec_domain.c Fri Mar 8 14:49:30 2002
+++ working-2.5.21-initorder/kernel/exec_domain.c Sun Jun 16 05:09:46 2002
@@ -275,14 +275,13 @@
};
static int __init
-abi_register_sysctl(void)
+abi_init(void)
{
register_sysctl_table(abi_root_table, 1);
return 0;
}
-__initcall(abi_register_sysctl);
-
+initcall(abi_init, init_before(device_initcalls));
EXPORT_SYMBOL(abi_defhandler_coff);
EXPORT_SYMBOL(abi_defhandler_elf);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/kernel/softirq.c working-2.5.21-initorder/kernel/softirq.c
--- linux-2.5.21/kernel/softirq.c Mon Jun 3 12:21:28 2002
+++ working-2.5.21-initorder/kernel/softirq.c Sun Jun 16 05:09:46 2002
@@ -412,4 +412,4 @@
return 0;
}
-__initcall(spawn_ksoftirqd);
+initcall(spawn_ksoftirqd, init_before(bus_initcalls)); /* Really? */
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/lib/crc32.c working-2.5.21-initorder/lib/crc32.c
--- linux-2.5.21/lib/crc32.c Wed Feb 20 17:56:42 2002
+++ working-2.5.21-initorder/lib/crc32.c Sun Jun 16 05:09:46 2002
@@ -564,7 +564,7 @@
crc32cleanup_be();
}
-fs_initcall(init_crc32);
+initcall(init_crc32, init_after(mm), init_before(device_initcalls));
module_exit(cleanup_crc32);
EXPORT_SYMBOL(crc32_le);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/mm/highmem.c working-2.5.21-initorder/mm/highmem.c
--- linux-2.5.21/mm/highmem.c Mon Jun 10 16:03:56 2002
+++ working-2.5.21-initorder/mm/highmem.c Sun Jun 16 05:09:46 2002
@@ -221,7 +221,9 @@
return 0;
}
-__initcall(init_emergency_pool);
+initcall(init_emergency_pool,
+ init_as_part_of(mm_initcalls),
+ init_before(mm_slab_init));
/*
* highmem version, map in to vec
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/mm/slab.c working-2.5.21-initorder/mm/slab.c
--- linux-2.5.21/mm/slab.c Mon May 13 12:00:40 2002
+++ working-2.5.21-initorder/mm/slab.c Sun Jun 16 05:09:46 2002
@@ -499,7 +499,7 @@
} while (sizes->cs_size);
}
-int __init kmem_cpucache_init(void)
+int __init mm_slab_init(void)
{
#ifdef CONFIG_SMP
g_cpucache_up = 1;
@@ -508,7 +508,7 @@
return 0;
}
-__initcall(kmem_cpucache_init);
+initcall(mm_slab_init, init_as_part_of(mm_initcalls));
/* Interface to system's page allocator. No need to hold the cache-lock.
*/
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/net/irda/af_irda.c working-2.5.21-initorder/net/irda/af_irda.c
--- linux-2.5.21/net/irda/af_irda.c Mon May 6 11:12:01 2002
+++ working-2.5.21-initorder/net/irda/af_irda.c Sun Jun 16 05:09:46 2002
@@ -2634,7 +2634,7 @@
return 0;
}
-late_initcall(irda_proto_init);
+initcall(irda_proto_init, init_after(device_initcalls));
/*
* Function irda_proto_cleanup (void)
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.21/scripts/build-initcalls working-2.5.21-initorder/scripts/build-initcalls
--- linux-2.5.21/scripts/build-initcalls Thu Jan 1 10:00:00 1970
+++ working-2.5.21-initorder/scripts/build-initcalls Sun Jun 16 05:12:13 2002
@@ -0,0 +1,116 @@
+#! /bin/sh
+# Given an objdump binary, and a list of object files, spit out C code to
+# call all the inits in order.
+
+# Hardcoded section orderings here.
+FIXED="mm bus device deprecated"
+
+# Don't do this in the top line, as we are invoked with sh explicitly.
+set -e
+
+if [ $# -le 1 ]; then
+ echo "Usage: $0 objdump objfile..." >&2
+ exit 1
+fi
+
+OBJDUMP="$1"
+shift
+
+# Get the structure sizes.
+INCLUDE_FILE=include/linux/init.h
+NAMELEN="`sed -n 's/[ ]*$//;/^[ ]*#[ ]*define[ ]*INITCALL_MAX_NAMELEN[ ]*/s///p' $INCLUDE_FILE`"
+NUMDEPS="`sed -n 's/[ ]*$//;/^[ ]*#[ ]*define[ ]*INITCALL_MAX_DEPS[ ]*/s///p' $INCLUDE_FILE`"
+if [ x"$NUMDEPS" = x ] || [ x"$NAMELEN" = x ] || [ x"`expr $NAMELEN % 16 2>/dev/null`" != x0 ]; then
+ echo "Invalid include file values: $NAMELEN and $NUMDEPS" >&2
+ exit 1
+fi
+# Objdump deals in 16-byte quantities.
+NAMELEN=`expr $NAMELEN / 16`
+
+# Simple numeric check (and also evaluate expression).
+NUMDEPS=`expr $NUMDEPS`
+
+# I hate mktemp, but tempfile isn't avail on RedHat
+TMPFILE="`mktemp \"${TMPDIR:-/tmp}/build-initcalls.XXXXXX\"`"
+TMPFILE2="`mktemp \"${TMPDIR:-/tmp}/build-initcalls2.XXXXXX\"`"
+REGEX="`mktemp \"${TMPDIR:-/tmp}/build-real.XXXXXX\"`"
+trap "echo exiting;rm -f \"$TMPFILE\" \"$TMPFILE2\" \"$REGEX\"" 0
+
+echo -n "s/\(" > "$REGEX"
+
+STATE=IN_NAME
+HEXABYTES=0
+FULLSTRING=""
+LASTOBSOLETE=""
+"$OBJDUMP" --section=.initcalls --full-contents "$@" |
+grep '^ *[0-9a-f][0-9a-f][0-9a-f][0-9a-f]' |
+while read POS HEX1 HEX2 HEX3 HEX4 STRING; do
+ # objdump uses . for non-printable, and we don't use real .s anyway.
+ FULLSTRING="$FULLSTRING`echo -n \"$STRING\" | tr -d .`"
+ HEXABYTES=`expr $HEXABYTES + 1`
+ if [ $HEXABYTES = $NAMELEN ]; then
+ case $STATE in
+ IN_NAME)
+ NAME="$FULLSTRING"
+ # Mentioned as a name: actual routine, not subsystem.
+ [ -z "$NAME" ] || echo -n "$NAME\|" >> $REGEX
+ STATE=IN_INITCALL_PRECEEDS
+ INITCALL_NUM=0
+ ;;
+ IN_INITCALL_PRECEEDS)
+ [ -z "$FULLSTRING" ] || echo "$NAME"-start "$FULLSTRING"
+ # Maintain link ordering for __initcalls
+ if [ x"$FULLSTRING" = x"obsolete_initcalls-end" ]; then
+ [ -z "$LASTOBSOLETE" ] || echo "$NAME" "$LASTOBSOLETE"
+ LASTOBSOLETE="$NAME"
+ fi
+ STATE=IN_INITCALL_FOLLOWS
+ ;;
+ IN_INITCALL_FOLLOWS)
+ [ -z "$FULLSTRING" ] || echo "$FULLSTRING" "$NAME"-end
+ INITCALL_NUM=`expr $INITCALL_NUM + 1`
+ if [ $INITCALL_NUM = $NUMDEPS ]; then
+ STATE=IN_NAME
+ else
+ STATE=IN_INITCALL_PRECEEDS
+ fi
+ ;;
+ esac
+ HEXABYTES=0
+ FULLSTRING=""
+ fi
+done > "$TMPFILE"
+
+# For everything which is an actual routine name, -start and -end are
+# the same. Use regex to strip them.
+echo "INVALID-NAME\)-\(start\|end\)/\1/g" >> "$REGEX"
+sed -f "$REGEX" < "$TMPFILE" > "$TMPFILE2"
+
+# Add in fixed orderings.
+prev_fixed=""
+for fixed in $FIXED; do
+ [ x"$prev_fixed" = x ] || echo ${prev_fixed}_initcalls-end ${fixed}_initcalls-start
+ echo ${fixed}_initcalls-start ${fixed}_initcalls-end
+ prev_fixed=$fixed
+done >> "$TMPFILE2"
+
+# Do the sort.
+tsort < "$TMPFILE2" > "$TMPFILE"
+
+# Generate output
+echo "/* Auto-generated by build-initcalls: DO NOT EDIT. */"
+echo "#include <linux/init.h>"
+echo ""
+echo "void __init do_initcalls(void)"
+echo "{"
+while read VALUE; do
+ case $VALUE in
+ *-end|*-start)
+ echo "/* $VALUE */"
+ ;;
+ *)
+ echo " { extern int __init_$VALUE(void); __init_$VALUE(); }"
+ ;;
+ esac
+done < "$TMPFILE"
+echo "}"
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* [parisc-linux] Unaligned access failures with apt-get on SMP K460.
From: Ryan Bradetich @ 2002-06-17 0:22 UTC (permalink / raw)
To: parisc-linux; +Cc: richard_hirst
Hello parisc-linux hackers,
I (with a lot of help from Richard) am looking into a problem with
apt-get .... on a SMP kernel for the K460.
The problem is that when I run apt-get <command> I get the following
error message:
apt-get(<PID>): unaligned access to 0x403ce094 at ip=0x4005e47f
This kernel has the DEBUG_UNALIGNED defined in
arch/parisc/kernel/unaligned.c to provide additional debug information
for unaligned accesses.
Here is the trace from the apt-get install sudo:
rebel:~# gdb /usr/bin/apt-get
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "hppa-linux"...(no debugging symbols
found)...
(gdb) break main
Breakpoint 1 at 0x24554
(gdb) run install sudo
Starting program: /usr/bin/apt-get install sudo
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Breakpoint 1, 0x00024554 in main ()
(gdb) continue
Continuing.
apt-get(165): unaligned access to 0x403ce094 at ip=0x4005e47f
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000000000000000000000000 Not tainted
r00-03 00000000 00044a20 40098df3 403ce08c
r04-07 00000038 40111868 faf00c18 00049da4
r08-11 00049da0 faf00f18 faf01368 faf00e4c
r12-15 000129e7 faf00bf0 faf00a88 faf00bcc
r16-19 faf006c8 0000000a faf005b8 40111868
r20-23 000022c8 00000166 00000000 403ce044
r24-27 faf01368 00000038 000022c8 00040220
r28-31 0004a900 400c65a7 faf01500 000282a3
sr0-3 00000097 0000008f 00000000 00000097
sr4-7 00000097 00000097 00000097 00000097
IASQ: 00000097 00000097 IAOQ: 4005e47f 4005e483
IIR: 0c751290 ISR: 00000097 IOR: 403ce094
CPU: 2 CR30: ee294000 CR31: 11111111
ORIG_R28: 00000001
unaligned.c:183:emulate_store <7>store r21 (0x00000166) to
00000097:403ce094 for 4 bytes
unaligned.c:365:handle_unaligned <7>ret = 0
apt-get (pid 165): Illegal instruction (code 8)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000000000000000000000000 Not tainted
r00-03 00000000 ee58c000 40098df3 403ce08c
r04-07 00000038 40111868 faf00c18 00049da4
r08-11 10356810 10356810 faf01368 faf00e4c
r12-15 000129e7 faf00bf0 faf00a88 faf00bcc
r16-19 ee294380 0000000a faf005b8 40111868
r20-23 000022c8 00000166 00000000 403ce044
r24-27 ee81c03c eeb3db00 000022c8 00040220
r28-31 0004a900 400c65a7 faf01500 000282a3
sr0-3 00000097 0000008f 00000000 00000097
sr4-7 00000097 00000097 00000097 00000097
IASQ: 00000097 00000097 IAOQ: 4005e483 4005e487
IIR: 48340048 ISR: 00000000 IOR: ee58c024
CPU: 2 CR30: ee294000 CR31: 11111111
ORIG_R28: 00000001
Program received signal SIGILL, Illegal instruction.
0x4005e480 in DynamicMMap::Allocate(unsigned long) ()
from /usr/lib/libapt-pkg-libc6.2-3.so.3.2
(gdb)
Here is the instruction dump:
(gdb) x/10i 0x4005e470
0x4005e470 <_ZN11DynamicMMap8AllocateEm+100>: copy r4,r25
0x4005e474 <_ZN11DynamicMMap8AllocateEm+104>: ldo -1(r21),r21
0x4005e478 <_ZN11DynamicMMap8AllocateEm+108>: copy r20,r26
0x4005e47c <_ZN11DynamicMMap8AllocateEm+112>: stw r21,8(sr0,r3)
0x4005e480 <_ZN11DynamicMMap8AllocateEm+116>: b,l 0x4005d76c
<_init+232>,r31
0x4005e484 <_ZN11DynamicMMap8AllocateEm+120>: add,l r20,r4,r20
0x4005e488 <_ZN11DynamicMMap8AllocateEm+124>: stw r20,4(sr0,r3)
0x4005e48c <_ZN11DynamicMMap8AllocateEm+128>: copy ret1,ret0
0x4005e490 <_ZN11DynamicMMap8AllocateEm+132>: ldw -54(sr0,sp),rp
0x4005e494 <_ZN11DynamicMMap8AllocateEm+136>: ldw -3c(sr0,sp),r4
(gdb)
The instruction causing the unaligned trap is:
0x4005e47c <_ZN11DynamicMMap8AllocateEm+112>: stw r21,8(sr0,r3)
As you can see from r3 (403ce08c) in the register dump is aligned on a
4-byte boundry. So the question is why is this trap being executed?
Also Richard thought the following two things looked wiered in the
register dump:
PSW is all 0's.
r30 is faf01500 ... isn't userspace stack usually 0xbf??????
Note: The apt-get commands work fine on a UP kernel, and I am running
against the unstable distribution. The same apt-get seems to work fine
on the J200 with an SMP kernel too.
Any thoughts or insight is appreciated :)
Thanks,
- Ryan
^ permalink raw reply
* Re: [patch] 2.4.19-pre10-ac2: O(1) scheduler merge, -A3.
From: Robert Love @ 2002-06-17 0:15 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, David S. Miller, linux-kernel, torvalds
In-Reply-To: <1024271844.1476.26.camel@sinai>
On Sun, 2002-06-16 at 16:57, Robert Love wrote:
> Another case of 2.4-ac being right
Attached patch brings over the sane bits from 2.4-ac: i.e. if Linus
merges this and Alan merges your patch minus my complaints, the two
trees will be in sync...
Robert Love
diff -urN linux-2.5.21/kernel/sched.c linux/kernel/sched.c
--- linux-2.5.21/kernel/sched.c Sat Jun 8 22:28:13 2002
+++ linux/kernel/sched.c Sun Jun 16 17:14:31 2002
@@ -762,8 +762,8 @@
list_t *queue;
int idx;
- if (unlikely(in_interrupt()))
- BUG();
+ BUG_ON(in_interrupt());
+
#if CONFIG_DEBUG_HIGHMEM
check_highmem_ptes();
#endif
@@ -1147,7 +1147,7 @@
/*
* Valid priorities for SCHED_FIFO and SCHED_RR are
- * 1..MAX_USER_RT_PRIO, valid priority for SCHED_OTHER is 0.
+ * 1..MAX_USER_RT_PRIO-1, valid priority for SCHED_OTHER is 0.
*/
retval = -EINVAL;
if (lp.sched_priority < 0 || lp.sched_priority > MAX_USER_RT_PRIO-1)
@@ -1710,15 +1710,15 @@
sigfillset(¤t->blocked);
set_fs(KERNEL_DS);
/*
- * The first migration thread is started on CPU #0. This one can migrate
- * the other migration threads to their destination CPUs.
+ * The first migration thread is started on CPU #0. This one can
+ * migrate the other migration threads to their destination CPUs.
*/
if (cpu != 0) {
while (!cpu_rq(cpu_logical_map(0))->migration_thread)
yield();
set_cpus_allowed(current, 1UL << cpu);
}
- printk("migration_task %d on cpu=%d\n",cpu,smp_processor_id());
+ printk("migration_task %d on cpu=%d\n", cpu, smp_processor_id());
ret = setscheduler(0, SCHED_FIFO, ¶m);
rq = this_rq();
@@ -1790,4 +1790,4 @@
while (!cpu_rq(cpu_logical_map(cpu))->migration_thread)
schedule_timeout(2);
}
-#endif
+#endif /* CONFIG_SMP */
^ permalink raw reply
* Re: [patch] 2.4.19-pre10-ac2: O(1) scheduler merge, -A3.
From: J.A. Magallon @ 2002-06-17 0:13 UTC (permalink / raw)
To: Robert Love; +Cc: Ingo Molnar, Alan Cox, David S. Miller, linux-kernel
In-Reply-To: <1024271844.1476.26.camel@sinai>
On 2002.06.17 Robert Love wrote:
>On Sun, 2002-06-16 at 10:00, Ingo Molnar wrote:
>
>> +int idle_cpu(int cpu)
>> +{
>> + return cpu_curr(cpu) == cpu_rq(cpu)->idle;
>> +}
>> +
>
>I did not include this in my original O(1) backport update because
>nothing in 2.4-ac seems to use it... so why include it?
>
Well, you asked...
- the irqbalance patch for p4 needs idle_cpu (and not sure about idle_task).
BTW, they were macros before...
- the bproc patch needs task_nice (you can be less interested in this, but
it does not hurt...)
So could I ask you, please
- to make public idle_[cpu,task], as macros or exported functions, here it
does not matter, irqbalance is not a module. Perhaps some other piece of code
could need them.
- to export all the set/get prio/nice interfaces
???
Thanks.
--
J.A. Magallon \ Software is like sex: It's better when it's free
mailto:jamagallon@able.es \ -- Linus Torvalds, FSF T-shirt
Linux werewolf 2.4.19-pre10-jam3, Mandrake Linux 8.3 (Cooker) for i586
gcc (GCC) 3.1.1 (Mandrake Linux 8.3 3.1.1-0.4mdk)
^ permalink raw reply
* Re: another new version of pageattr caching conflict fix for 2.4
From: Albert D. Cahalan @ 2002-06-17 0:08 UTC (permalink / raw)
To: Andi Kleen
Cc: Eric W. Biederman, Andi Kleen, Andrea Arcangeli, Benjamin LaHaise,
linux-kernel, Richard Brunner, mark.langsdorf
In-Reply-To: <20020617013732.A14867@wotan.suse.de>
Andi Kleen writes:
>> the same problems if the agp aperture was marked write-back, and the
>
> AGP aperture is uncacheable, not write-back.
>
>> memory was marked uncacheable. My gut impression is to just make the
>> agp aperture write-back cacheable, and then we don't have to change
>> the kernel page table at all. Unfortunately I don't expect the host
>
> That would violate the AGP specification.
>
>> bridge with the memory and agp controllers to like that mode,
>> especially as there are physical aliasing issues.
>
> exactly.
You can do whatever you want, as long as...
1. you have cache control instructions and use them
2. the bridge ignores the coherency protocol (no machine check)
Most likely you should make the AGP memory write-back
cacheable. This requires some care regarding cache lines,
but ought to be faster.
>>> Fixing the MTRRs is fine, but it is really outside the scope of my patch.
>>> Just changing the kernel map wouldn't be enough to fix wrong MTRRs,
>>> because it wouldn't cover highmem.
>>
>> My preferred fix is to use PAT, to override the buggy mtrrs. Which
>> brings up the same aliasing issues. Which makes it related but
>> outside the scope of the problem.
>
> I don't follow you here. IMHO it is much easier to fix the MTRRs in the
> MTRR driver for those rare buggy BIOS (if they exist - I've never seen one)
> than to hack up all of memory management just to get the right bits set.
> I see no disadvantage of using the MTRRs and it is lot simpler than
> PAT and pte bits.
For non-x86 one must "hack up all of memory management" anyway.
Example: There aren't any MTRRs on the PowerPC, but every page
has 4 memory type bits. It's not OK to map something more than
one way at the same time. Large "pages" (256 MB each) are used
to cover all of non-highmem physical memory.
^ permalink raw reply
* Re: [patch] 2.4.19-pre10-ac2: O(1) scheduler merge, -A3.
From: Robert Love @ 2002-06-16 23:57 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, David S. Miller, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0206161809480.9633-200000@e2>
On Sun, 2002-06-16 at 10:00, Ingo Molnar wrote:
> Feature backports:
>
> - nr_uninterruptible optimization. (This is a fairly straightforward
> and risk-less feature, and since it also made the backport easier, i
> included it.)
Yah, I agree - this is safe and good.
> - sched_setaffinity() & sched_getaffinity() syscalls on x86.
Do we want to introduce this into 2.4 now? I realize 2.4-ac is not 2.4
proper, but if there is a chance this interface could change...
> - BUG_ON(in_interrupt());
> -
> + if (unlikely(in_interrupt()))
> + BUG();
Eh, why do this? BUG_ON is the same effect and it is more readable to
me... seems better that 2.5 gets 2.4-ac's behavior instead of the other
way around.
> +int idle_cpu(int cpu)
> +{
> + return cpu_curr(cpu) == cpu_rq(cpu)->idle;
> +}
> +
I did not include this in my original O(1) backport update because
nothing in 2.4-ac seems to use it... so why include it?
> /*
> * Valid priorities for SCHED_FIFO and SCHED_RR are
> - * 1..MAX_USER_RT_PRIO-1, valid priority for SCHED_OTHER is 0.
> + * 1..MAX_USER_RT_PRIO, valid priority for SCHED_OTHER is 0.
> */
Another case of 2.4-ac being right: the priority range is
1..MAX_USER_RT_PRIO-1 (i.e. 1 to 99, inclusive).
> /*
> - * The first migration thread is started on CPU #0. This one can
> - * migrate the other migration threads to their destination CPUs.
> + * The first migration thread is started on CPU #0. This one can migrate
> + * the other migration threads to their destination CPUs.
> */
> if (cpu != 0) {
> while (!cpu_rq(cpu_logical_map(0))->migration_thread)
> yield();
> set_cpus_allowed(current, 1UL << cpu);
> }
> - printk("migration_task %d on cpu=%d\n", cpu, smp_processor_id());
> + printk("migration_task %d on cpu=%d\n",cpu,smp_processor_id());
> ret = setscheduler(0, SCHED_FIFO, ¶m);
> rq = this_rq();
> @@ -1632,5 +1813,4 @@
> while (!cpu_rq(cpu_logical_map(cpu))->migration_thread)
> schedule_timeout(2);
> }
> -
> -#endif /* CONFIG_SMP */
> +#endif
I think all three of these hunks look better in 2.4-ac... in all three
cases, the formatting seems better than in 2.5 IMO.
Robert Love
^ permalink raw reply
* Re: [CHECKER] 37 stack variables >= 1K in 2.4.17
From: Alexander Viro @ 2002-06-16 23:57 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: linux-kernel
In-Reply-To: <UTC200206162205.g5GM5eJ05123.aeb@smtp.cwi.nl>
On Mon, 17 Jun 2002 Andries.Brouwer@cwi.nl wrote:
> >> The result of Step One is that the loop no longer touches all
> >> filesystems but lives entirely in namei.c. So, the second patch,
> >> that only changes namei.c can change the recursion into iteration.
> >> Maybe tomorrow or the day after.
>
> > Obvious breakage: nd->flags can be clobbered by __vfs_follow_link(),
> > so your do_follow_link() and friends are broken.
>
> Yes, I know. No doubt you are able to fix that by reading that bit
> before calling __vfs_follow_link(). It will be repaired fully
> automatically tomorrow or the day after when __vfs_follow_link()
> disappears altogether.
>
> But that is the microscopic criticism. I was more interested in
> hearing comments on the global setup.
I don't see global setup here - just a (rather messy) change of API.
The really interesting question is how you'll handle namei.c code.
Bringing the call of __vfs_follow_link() into do_follow_link() is
not interesting in itself - you still have recursion to eliminate and
that's where the hell will begin. Change of ->follow_link() prototype
per se doesn't buy anything and is as you admit kludgy. If you need
it for really interesting stuff - please do show that stuff.
^ permalink raw reply
* Re: [PATCH] 2.4-ac: sparc64 support for O(1) scheduler
From: Robert Love @ 2002-06-16 23:45 UTC (permalink / raw)
To: Ingo Molnar; +Cc: David S. Miller, alan, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0206161710240.7461-100000@e2>
On Sun, 2002-06-16 at 08:19, Ingo Molnar wrote:
> Linus applied them already, they will be in 2.5.22. They fix real bugs and
> i've seen no problems on my testboxes. Those bits are a must for SMP x86
> and Sparc64 as well, there is absolutely no reason to selectively delay
> their backmerge. Besides the last task_rq_lock() optimization which got
> undone in 2.5 already, all the recent scheduler bits i posted are needed.
I know they are fine (I looked over them) and I saw Linus took them, but
2.5.22 is not yet out and I did not see any reason to rush to new bits
to Alan for 2.4 when we could wait a bit and make sure 2.5 proves them
fine...
My approach thus far with 2.5 -> 2.4 O(1) backports has been one of
caution and it has worked fine thus far. I figure, what is the rush?
Robert Love
^ permalink raw reply
* Re: [parisc-linux] HP PA 715/50 installation trouble
From: Masliy Alex @ 2002-06-15 8:04 UTC (permalink / raw)
To: Ralf Hildebrandt; +Cc: parisc-linux
In-Reply-To: <20020615075209.GK8736@charite.de>
On Sat, 15 Jun 2002 09:52:09 +0200
Ralf Hildebrandt <Ralf.Hildebrandt@charite.de> wrote:
>> At first, I tried to install from CDROM. In the proccess of booting the
>> following messages were printed:
>> ---------------
>> Trying to scsi.4.0
>> Failed to initialize scsi.4.0
>> ENTRY_INIT status = -13
RH> Hmm. Was this drive working with that box under HP-UX?
Yes, of course. I was mounted the Debian Install Disk under HP-UX.
But it is old device (August 1993).
--
Sincerilly,
Masliy Alex mailto:masliy@kfti.knc.ru
^ permalink raw reply
* Re: another new version of pageattr caching conflict fix for 2.4
From: Andi Kleen @ 2002-06-16 23:37 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Andi Kleen, Andrea Arcangeli, Benjamin LaHaise, linux-kernel,
Richard Brunner, mark.langsdorf
In-Reply-To: <m1y9dft2t8.fsf@frodo.biederman.org>
> > MTRRs work on physical, not virtual memory, so they have no aliasing
> > issues.
>
> Doesn't the AGP aperture cause a physical alias? Leading to strange
Yes. That's what this patch is all about.
> the same problems if the agp aperture was marked write-back, and the
AGP aperture is uncacheable, not write-back.
> memory was marked uncacheable. My gut impression is to just make the
> agp aperture write-back cacheable, and then we don't have to change
> the kernel page table at all. Unfortunately I don't expect the host
That would violate the AGP specification.
> bridge with the memory and agp controllers to like that mode,
> especially as there are physical aliasing issues.
exactly.
>
> > Fixing the MTRRs is fine, but it is really outside the scope of my patch.
> > Just changing the kernel map wouldn't be enough to fix wrong MTRRs,
> > because it wouldn't cover highmem.
>
> My preferred fix is to use PAT, to override the buggy mtrrs. Which
> brings up the same aliasing issues. Which makes it related but
> outside the scope of the problem.
I don't follow you here. IMHO it is much easier to fix the MTRRs in the
MTRR driver for those rare buggy BIOS (if they exist - I've never seen one)
than to hack up all of memory management just to get the right bits set.
I see no disadvantage of using the MTRRs and it is lot simpler than
PAT and pte bits.
-Andi
^ permalink raw reply
* Re: scanner not autoloading, and wlan card
From: David Brownell @ 2002-06-16 23:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <marc-linux-hotplug-102426501212566@msgid-missing>
> also, I have a usb printer, hp960cse, that does not seem to autoload
> either.
> it's /dev/usb/lp0
>
> hotplug seems to find most other items, but not these two,
USB hotplug is driven by data found in the USB device and interface
descriptors. It's quite possible that the drivers in your kernel don't
happen to know about your scanner and/or printer devices.
You didn't say what kernel you're using ... does 2.4.19-pre10 fail
in that way? If so, send the relevant /proc/bus/usb/devices info to
the maintainers of the "printer" and "scanner" drivers.
> and even
> though i have this
>
> # usb module match_flags idVendor idProduct bcdDevice_lo
> bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol
> bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info
> wusb11 0x0003 0x066b 0x2212 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> prism2usb 0x0003 0x066b 0x2212 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> 0x00
>
> and i have something called wusb11 in usb/ dir to execute on plugging it in
> is that how it goes?
> how do i find out if it's correct for usb.usermap?
There are some suggestions on the linux-hotplug.sf.net website about
how to debug problems in driver hotplugging:
http://linux-hotplug.sourceforge.net/?selectedÞbug
If this is the "prism2usb" driver I found out about recently, that
driver doesn't yet know about hotplugging. It needs to include a
MODULE_DEVICE_TABLE and use it correctly, then "depmod" will find it
and list it in /lib/modules/$(uname -r)/modules.usbmap and it'll just
hotplug normally.
> is the first part the script it executes in usb/?
The first field is the name of the logical driver, which may also have
a usermode setup script ... if there's an executable of that name in
/etc/hotplug/usb it should run that when a device associated with that
kernel driver gets hotplugge. You should be able to just name your
script "prism2usb" and install it, without needing to make any entries
in "usb.handmap" ... that file should mostly be needed for drivers that
only use "usbfs" and have no other kernel code.
- Dave
_______________________________________________________________
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* RE: MLS changes
From: Vanuxem gregory @ 2002-06-16 23:18 UTC (permalink / raw)
To: SELinux Mailing, Stephen Smalley
In-Reply-To: <Pine.GSO.4.33.0206041536520.3949-100000@raven>
> On Tue, 4 Jun 2002, Vanuxem gregory wrote:
>
> > I tried it and I had to change a lot of
> > permissions !!!
>
> By the way, could you elaborate on what you mean by this statement? Do
> you mean that you had to change the mappings from SELinux permissions to
> MLS base permissions in policy/mls? What exactly did you have to change
> and why? Are you trying to use MLS ranges for some of the initial SID
> contexts?
For example
login => read and write tty but now with the last version all is good
=> fd use " " "" ""
process sigchld := (login => init) (actually Init (+ mlstrustedreader) or
sigchld = none)
Some other things, first all domains run in public level (unclassified ->
public -> confidential ->secret ->top-secret ).
For this I change de default level in setfile code but i keep the
unclassified level in kernel source.
Since there is some change in kernel source a lot of thing work well now.
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [linux-usb-devel] Re: /proc/scsi/map
From: James Bottomley @ 2002-06-16 23:14 UTC (permalink / raw)
To: Oliver Neukum
Cc: James Bottomley, David Brownell, Andries.Brouwer, garloff,
linux-kernel, linux-scsi, sancho, linux-usb-devel,
linux1394-devel, dougg
In-Reply-To: <200206170038.51403.oliver@neukum.name>
oliver@neukum.name said:
> But the drivers already know, or would have to be taught to know about
> it. Somewhence that information has to come. You cannot avoid that
> effort.
Not necessarily: consider the SCSI WWN, which is supported by most modern SCSI
devices. The driver never probes for or asks for this. Nowhere in the
current SCSI code do we ask for this. However user level commands (like
sg_inq) can formulate the 0x83 page inquiry to get this and return the output.
This works today with the current driver.
> That is wrong. You'd need a common method to determine device type and
> several methods of passing guid. You are better off in implementing
> one common way of getting at that information, which shouldn't be too
> hard, as all the generic layer would have to do is pass up that
> information.
but the complexity is in the "common method to determine device type and
several methods of passing guid". Even for a simple SCSI disk, there's no one
universal way of getting a unique id (let alone when we add the usb devices
masquerading as scsi disks into the mix). That will lead us to scanning a
list of inquiry strings to see what the disk is and determine what globally
unique ID it supports. Since we have to implement a lookup table just to
determine how to get the unqiue id, it's far better off being done outside the
kernel.
James
^ 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.