On Thu, Jan 31, 2002 at 04:30:54PM -0800, David S. Miller wrote:
> From: Alan Cox <[email protected]>
> Date: Fri, 1 Feb 2002 00:42:44 +0000 (GMT)
>
> I'd like to eliminate lots of the magic weird cases in Config.in too - but
> by making the language express it. Something like
>
> tristate_orif "blah" CONFIG_FOO $CONFIG_SMALL
>
> This doesn't solve the CRC32 case. What if you want
> CONFIG_SMALL, yet some net driver that needs the crc32
> routines?
Maybe not in this hypothetical future situation, but currently makefile
magic was added for crc32 specifically to ensure that it is linked
in when needed... even when CONFIG_CRC32=n.
The Config.in for crc32 only exists for the case where no driver in the
built kernel uses it... but a 3rd party module might want it.
Jeff
From: Jeff Garzik <[email protected]>
Date: Thu, 31 Jan 2002 22:46:35 -0500
Maybe not in this hypothetical future situation, but currently makefile
magic was added for crc32 specifically to ensure that it is linked
in when needed... even when CONFIG_CRC32=n.
The Config.in for crc32 only exists for the case where no driver in the
built kernel uses it... but a 3rd party module might want it.
My point is this: Having to say something like "CONFIG_INEED_CRC32"
for each driver that needs it is just plain stupid and a total eye
sore.
It would be really great if, some day, you just add your source
file(s) to drivers/net and that is the only thing you ever touch. You
DO NOT touch Makefiles, you DO NOT touch Config.in files, you DO NOT
add Config.help entries.
The Makefile rules are auto-generated from keys in the *.c file(s), as
are the Config.in and help entries. Ie. cp driver.[ch]
linux/drivers/net and then simply rebuild the tree.
Think of what kind of pains this would save from a maintainership
point of view. When multiple new drivers are added at once we run
into all kinds of conflict issues today, whereas my scheme would do
away with that for all cases except totally new subsystems. (but I
think that could be automated in a similar fashion as well)
I have this feeling Keith Owens is going to scream "the new build
system DOES EXACTLY THAT!" If so, that's fscking great. :-)
That is the kind of direction I'd like to see things going in. The
lib config thing checking "if LANCE or 8130TOO or ... then force CRC32
on", on the other hand, is just garbage. It is rediculious to expect
J. Random driver author to know to put junk into weird places like
that just to get at the crc32 routines.
On Fri, 1 Feb 2002 00:12:42 -0500,
Jeff Garzik <[email protected]> wrote:
>On Fri, Feb 01, 2002 at 04:10:13PM +1100, Keith Owens wrote:
>> Why can't I do it? Linus wants the current method, where monolithic
>> Makefiles control initialization order.
>
>Wrong, we have multi-level initcalls now.
I know, it makes it even harder to see what the initialization order
is. Some are controlled by the Makefile/subdirs order, some by special
calls in the code.
On Thu, 31 Jan 2002 20:25:09 -0800 (PST),
"David S. Miller" <[email protected]> wrote:
>It would be really great if, some day, you just add your source
>file(s) to drivers/net and that is the only thing you ever touch. You
>DO NOT touch Makefiles, you DO NOT touch Config.in files, you DO NOT
>add Config.help entries.
>...
>I have this feeling Keith Owens is going to scream "the new build
>system DOES EXACTLY THAT!" If so, that's fscking great. :-)
Close but not quite. I would love to do exactly that and remove all
the monolithic files like Configure.*, Config.in and Makefile. But I
can't.
The only thing stopping me writing a simple "install this source and
the kernel detects it" model is initialization order, module_init ->
.text.init. The initialization order is controlled by the order of
entries in Makefiles and subdirs entries between Makefiles. That
sucks, as the recent problems with crc32.o have shown.
Two years ago I suggested breaking the implicit nexus between Makefile
order and initialization order, by adding new directives to explicitly
define initialization order - where required. For example, group
memory must initialize before group network, within group network
driver ne2000 must initialize before driver eepro100.
As long as Makefiles control initialization order, you need monolithic
Makefiles. Adding another layer to say which order the make entries
for each source are to be combined just compounds the problem. Let me
separate the initialization order from Makefiles and I will happily
give you "add a source and kbuild autobuilds it" model.
Why can't I do it? Linus wants the current method, where monolithic
Makefiles control initialization order.
http://www.mail-archive.com/[email protected]/msg10645.html
On Fri, Feb 01, 2002 at 04:10:13PM +1100, Keith Owens wrote:
> Why can't I do it? Linus wants the current method, where monolithic
> Makefiles control initialization order.
Wrong, we have multi-level initcalls now.
Jeff
From: Keith Owens <[email protected]>
Date: Fri, 01 Feb 2002 16:10:13 +1100
As long as Makefiles control initialization order, you need monolithic
Makefiles.
With the current 2.5.x scheme, you can put your init into the
appropriate group. Makefiles only control init order within
the groups.
I actually like this solution a lot.
On Thu, 31 Jan 2002 22:01:21 -0800 (PST),
"David S. Miller" <[email protected]> wrote:
> From: Keith Owens <[email protected]>
> Date: Fri, 01 Feb 2002 16:10:13 +1100
>
> As long as Makefiles control initialization order, you need monolithic
> Makefiles.
>
>With the current 2.5.x scheme, you can put your init into the
>appropriate group. Makefiles only control init order within
>the groups.
But you still need monolithic makefiles.
They also control order across directories as well, including up one,
down two constructs like this.
obj-$(CONFIG_SCSI_AHA1740) += aha1740.o
ifeq ($(CONFIG_SCSI_AIC7XXX),y)
obj-$(CONFIG_SCSI_AIC7XXX) += aic7xxx/aic7xxx_drv.o
endif
obj-$(CONFIG_SCSI_AIC7XXX_OLD) += aic7xxx_old.o
and the abomination
obj-$(CONFIG_SCSI_LASI700) += lasi700.o 53c700.o
subdir-$(CONFIG_ARCH_ACORN) += ../acorn/scsi
obj-$(CONFIG_ARCH_ACORN) += ../acorn/scsi/acorn-scsi.o
obj-$(CONFIG_CHR_DEV_ST) += st.o
BTW, the grouped initcalls in the code are exactly what I proposed in
October 2000 and was shouted down. Except my proposal would have put
all the initialization order information together, instead of putting
some information in the source and some in the Makefiles. It is now
even harder to see the precise order, you have to check which type of
initcall each source is using in addition to scanning the makefile
order.
From: Keith Owens <[email protected]>
Date: Fri, 01 Feb 2002 17:11:05 +1100
Except my proposal would have put all the initialization order
information together, instead of putting some information in the
source and some in the Makefiles.
NONE OF IT IS IN THE MAKEFILES! Please change your perspective
to see this!
If you have a dependency concern, you put yourself in the
right initcall group. You don't depend ever on the order within the
group, thats the whole idea. You can't depend on that, so you must
group things correctly.
Again, if you have some dependency within the initcall group, then
you're grouping things incorrectly. If the grouping is selected
properly, you could link in the total opposite order all the objects
and it still would work out fine.
I think your complaints are for problems that don't really exist.
On Thu, 31 Jan 2002 22:26:43 -0800 (PST),
"David S. Miller" <[email protected]> wrote:
>If you have a dependency concern, you put yourself in the
>right initcall group. You don't depend ever on the order within the
>group, thats the whole idea. You can't depend on that, so you must
>group things correctly.
Again this is exactly what I argued back in 2000. I have long held
that the kernel link order is over defined where it should be fuzzy.
Defining an order between groups but not within groups is exactly what
I wanted but I was told that the initialization order must be
explicitly and fully specified for the entire kernel. Nice to see that
I have been proved right, pity it took this long. C'est la vie.
The Makefiles still control order within the .text.init section
(__init, module_init). Many drivers depend on the Makefile getting
that order correct, otherwise probes stuff up. But which entries are
order sensitive and which ones are from a developer picking a random
place to insert obj-$(CONFIG) is anyone's guess.
On Fri, Feb 01, 2002 at 03:03:13PM +0000, Alan Cox wrote:
> > If you have a dependency concern, you put yourself in the
> > right initcall group. You don't depend ever on the order within the
> > group, thats the whole idea. You can't depend on that, so you must
> > group things correctly.
>
> This was proposed right back at the start. Linus point blank vetoed it.
My ideal would be to express dependencies in driver.conf (when that is
implemented), and that will in turn affect the link order by
autogenerating part of vmlinux.lds. Until then, initcall groups are
fine with me...
Jeff
> If you have a dependency concern, you put yourself in the
> right initcall group. You don't depend ever on the order within the
> group, thats the whole idea. You can't depend on that, so you must
> group things correctly.
This was proposed right back at the start. Linus point blank vetoed it.
Alan
On Fri, Feb 01, 2002 at 09:55:10AM -0500, Jeff Garzik wrote:
> On Fri, Feb 01, 2002 at 03:03:13PM +0000, Alan Cox wrote:
> > > If you have a dependency concern, you put yourself in the
> > > right initcall group. You don't depend ever on the order within the
> > > group, thats the whole idea. You can't depend on that, so you must
> > > group things correctly.
> >
> > This was proposed right back at the start. Linus point blank vetoed it.
Hi Linus,
I've found that multiple level initcalls went into kernel
behind my back, so you can throw away my yesterday patch
which converted lib.a => lib.o, and apply this one.
I decided to use fs_initcall level, as nobody is using this
yet. If jffs2 will get initialized by fs_initcall, we'll have
to switch init_crc32 from fs_initcall to arch_initcall or
even sooner - crc32 initialization needs only working
kmalloc, nothing else (and it could use static buffer happilly,
as zeroes compress very good), so subsys_initcall could work
too.
This patch does NOT solve problem with useless option CRC32 in
Config.in, as we compile crc32.o, but nobody picks it up for kernel
link. It is impossible to have .a for this directory unless we'll
start using --undefined= linker option to bring crc32 into final
image.
Best is probably applying this over lib.a=>lib.o patch. Then
ordering is ensured by initcall level, and not by Makefiles,
and in addition CRC32 makefile option really does something...
Best regards,
Petr Vandrovec
[email protected]
[Patch tested with both lib.a and lib.o - it boots correctly
in both cases]
diff -urdN linux/lib/crc32.c linux/lib/crc32.c
--- linux/lib/crc32.c Tue Jan 15 19:08:05 2002
+++ linux/lib/crc32.c Fri Feb 1 14:54:28 2002
@@ -564,7 +564,7 @@
crc32cleanup_be();
}
-module_init(init_crc32);
+fs_initcall(init_crc32);
module_exit(cleanup_crc32);
EXPORT_SYMBOL(crc32_le);
Is there actually anybody out there for whoom the vga=ask kernelparamter
followed by a mode scan actually works? For me personally I never
encountered
*any* single one computer wher ethis wouldn't hang the system entierly, so
I wonder whatever the wholesale option ain't borken?
kernel 2.2.X ati rage,ati radeon vga=ask works (as vesa)
kernel 2.4.X 800x600 mode didn't tested vga=ask
regards,
Zoran
On Fri, 1 Feb 2002, Martin Dalecki wrote:
> Date: Fri, 01 Feb 2002 16:29:39 +0100
> From: Martin Dalecki <[email protected]>
> To: [email protected]
> Subject: VESA Anybody out there
>
> Is there actually anybody out there for whoom the vga=ask kernelparamter
> followed by a mode scan actually works? For me personally I never
> encountered
> *any* single one computer wher ethis wouldn't hang the system entierly, so
> I wonder whatever the wholesale option ain't borken?
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Martin Dalecki wrote:
> Is there actually anybody out there for whoom the vga=ask kernelparamter
> followed by a mode scan actually works? For me personally I never
> encountered
> *any* single one computer wher ethis wouldn't hang the system
> entierly, so
> I wonder whatever the wholesale option ain't borken?
On my computers it has never been of any use, but it didn't crash. It
only returned the normal screen modes (the text ones) and nothing else.
[email protected] said:
> I decided to use fs_initcall level, as nobody is using this yet. If
> jffs2 will get initialized by fs_initcall, we'll have to switch
> init_crc32 from fs_initcall to arch_initcall or even sooner - crc32
> initialization needs only working kmalloc, nothing else (and it could
> use static buffer happilly, as zeroes compress very good), so
> subsys_initcall could work too.
JFFS2 won't actually use the crc32 routines till it tries to mount a file
system, so you shouldn't have a problem unless you try to mount the rootfs
before init_crc32().
--
dwmw2
Davidovac Zoran wrote:
>kernel 2.2.X ati rage,ati radeon vga=ask works (as vesa)
>kernel 2.4.X 800x600 mode didn't tested vga=ask
>
I really mean the "scan" command after VGA ask.
Do I have to understand that you're using : "vga=ask scan" ?
this can't work, cause it doesn't mean anything.
The syntax is "vga=ask" _or_ "vga=scan"
Or, if you prefer, 'ask' is a special scan code you can put, that will ask
you (at boot time) which one you want (you'll get a list of scancode
supported by your graphic card to choose from)
best wishes,
Thomas
On Friday 01 February 2002 17:21, Martin Dalecki wrote:
> Davidovac Zoran wrote:
> >kernel 2.2.X ati rage,ati radeon vga=ask works (as vesa)
> >kernel 2.4.X 800x600 mode didn't tested vga=ask
>
> I really mean the "scan" command after VGA ask.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
1 ??????? 2002 19:21, Martin Dalecki ???????:
> Davidovac Zoran wrote:
> >kernel 2.2.X ati rage,ati radeon vga=ask works (as vesa)
> >kernel 2.4.X 800x600 mode didn't tested vga=ask
>
> I really mean the "scan" command after VGA ask.
2.4.17 mga G400, i810 not problem at all
--
Best regards,
Sergey S. Kostyliov <[email protected]>
Dear diary, on Fri, Feb 01, 2002 at 04:29:39PM CET, I got a letter, where
Martin Dalecki <[email protected]> told me, that...
> Is there actually anybody out there for whoom the vga=ask kernelparamter
> followed by a mode scan actually works? For me personally I never encountered
> *any* single one computer wher ethis wouldn't hang the system entierly, so I
> wonder whatever the wholesale option ain't borken?
Oh, it somewhere hangs? I never encountered *any* single one computer where
this would hang the system :-).
Trident 9440 -> 2.1.x, 2.2.x, 2.4.x -> No problem
Trident 9660 -> 2.2.x, 2.4.x -> No problem
S3 Trio3D -> 2.2.x, 2.4.x -> No problem
Those are my home videocards, I know it works with others as well (just can't
name them just now).
--
Petr "Pasky" Baudis
* UN*X programmer && admin * IPv6 guy (XS26 co-coordinator)
* elinks maintainer * FreeCiv AI hacker
* IRCnet local operator
.
"Something has fallen on us that falls very seldom on men; perhaps the worst
thing that can fall on them.
We have found the truth; and the truth makes no sense."
-- Father Brown
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/
At 16:21 01/02/02, Martin Dalecki wrote:
>Davidovac Zoran wrote:
>
>>kernel 2.2.X ati rage,ati radeon vga=ask works (as vesa)
>>kernel 2.4.X 800x600 mode didn't tested vga=ask
>I really mean the "scan" command after VGA ask.
Works fine on all systems I have ever tried it on (so that would be various
Matrox AGP cards and one or more of random SiS PCI card, random Trident
ISA, random Diamond Stealth - I've been changing cards a lot in my server
box and in my development box and am not sure on which I have used it and
on which not...). This would be all on 2.4.x kernels by the way, haven't
needed to use it recently.
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
Thomas Capricelli wrote:
>
>Do I have to understand that you're using : "vga=ask scan" ?
>this can't work, cause it doesn't mean anything.
>
>The syntax is "vga=ask" _or_ "vga=scan"
>
>Or, if you prefer, 'ask' is a special scan code you can put, that will ask
>you (at boot time) which one you want (you'll get a list of scancode
>supported by your graphic card to choose from)
>
I use vga=ask as kernel parameter
and type scan at the dialogue, which than hangs the system *allways*.
same for me,
, but when using scan on my laptop it took around 5 minutes to discover the
textmodes (while the screen was entirely black, i've rebooted the laptop
several times, 'cause i thought that my system was dead)
-a.
Andreas Happe wrote:
>same for me,
>, but when using scan on my laptop it took around 5 minutes to discover the
>textmodes (while the screen was entirely black, i've rebooted the laptop
>several times, 'cause i thought that my system was dead)
>
I didn't wait *that* long for sure....
Apparently on my desk system the scan is returnning after a long time as
well.
Hi!
> Is there actually anybody out there for whoom the vga=ask kernelparamter
> followed by a mode scan actually works? For me personally I never
> encountered
> *any* single one computer wher ethis wouldn't hang the system entierly, so
> I wonder whatever the wholesale option ain't borken?
Works for me.
ask [email protected], he coded that.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa