Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Alan Cox]

> What I did propose was to eliminate the Config.in special casings all
> over the place to turn this stuff on.  It's just a wart when I look at
> it.  But you don't seem to like that idea so I'll drop it.

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

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   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?

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Jeff Garzik]

On Thu, Jan 31, 2002 at 04:30:54PM -0800, David S. Miller wrote:
>    From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>    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

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[H. Peter Anvin]

Followup to:  <20020131.163054.41634626.davem@redhat.com>
By author:    "David S. Miller" <davem@redhat.com>
In newsgroup: linux.dev.kernel
>    
>    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?
> 

We could do it something like what I did with inflate_fs -- build it
as a module if the kernel proper doesn't need it (and modules are
enabled.)

It *does* mean the configure rules need to contain these dependencies,
though.

crc32 is an interesting case... you can create code to make the tables
with a very small amount of code.  This saves space on disk, but not
in memory; in fact, if you can't jettison this code you lose in
memory...

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Jeff Garzik]

On Thu, Jan 31, 2002 at 08:18:01PM -0800, H. Peter Anvin wrote:
> It *does* mean the configure rules need to contain these dependencies,
> though.

No.  The Makefile not configure needs to mention these dependencies.

Look at how crc32 is -really- included in the kernel.

	Jeff

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[David S. Miller]

   From: Jeff Garzik <garzik@havoc.gtf.org>
   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.

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Jeff Garzik]

On Thu, Jan 31, 2002 at 08:25:09PM -0800, David S. Miller wrote:
>    From: Jeff Garzik <garzik@havoc.gtf.org>
>    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.

I agree.

This is -not- the situation now, and it will never be the situation.

Did you read drivers/net/Makefile.lib ?

Another example, take a look at drivers/video/Config.in.  We actually do
not need those hideously long if statements "if foofb or barfb or bazfb"...
Makefile rules clean that shit up nicely.


> 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.

You are preaching to the choir.  ;-)


> 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.

Close...  Check out this thread from December.  I agree with Linus
we need metadata files (driver.conf), not yanking all that info out
of the source code.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.3/0969.html
	and
http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.3/0801.html

To sum, Makefile rules are better than Config.in garbage because it can
be far more modular, and more resistant to breakage.  But, for the
longer term, we want 8139too.conf and lance.conf and...

Regards,

	Jeff

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Keith Owens]

On Thu, 31 Jan 2002 20:25:09 -0800 (PST), 
"David S. Miller" <davem@redhat.com> 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/linux-kernel@vger.kernel.org/msg10645.html

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Jeff Garzik]

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

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Keith Owens]

On Fri, 1 Feb 2002 00:12:42 -0500, 
Jeff Garzik <garzik@havoc.gtf.org> 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.

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Horst von Brand]

Keith Owens <kaos@ocs.com.au> said:

[...]

> 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.

Just to repeat myself: This is clearly a problem for tsort(1): Give
restrictions of the form "This has to come after that" (perhaps a special
comment at the start of the file containing the init function?), tsort that
and pick the order out of the result. Should be a few lines of script. No
central repository for the dependencies, no messing around with half the
world to fix dependencies. Plus they become explicit, which they aren't
today.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Keith Owens]

On Fri, 01 Feb 2002 14:42:11 +0100, 
Horst von Brand <brand@jupiter.cs.uni-dortmund.de> wrote:
>Keith Owens <kaos@ocs.com.au> said:
>> 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.
>
>Just to repeat myself: This is clearly a problem for tsort(1): Give
>restrictions of the form "This has to come after that" (perhaps a special
>comment at the start of the file containing the init function?), tsort that
>and pick the order out of the result. Should be a few lines of script. No
>central repository for the dependencies, no messing around with half the
>world to fix dependencies. Plus they become explicit, which they aren't
>today.

Just to repeat myself: That is exactly what I want to do.  Linus vetoed
it in October 2000.

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Horst von Brand]

Keith Owens <kaos@ocs.com.au> said:
> On Fri, 01 Feb 2002 14:42:11 +0100, 
> Horst von Brand <brand@jupiter.cs.uni-dortmund.de> wrote:
> >Keith Owens <kaos@ocs.com.au> said:
> >> 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.

> >Just to repeat myself: This is clearly a problem for tsort(1): Give
> >restrictions of the form "This has to come after that" (perhaps a special
> >comment at the start of the file containing the init function?), tsort that
> >and pick the order out of the result. Should be a few lines of script. No
> >central repository for the dependencies, no messing around with half the
> >world to fix dependencies. Plus they become explicit, which they aren't
> >today.

> Just to repeat myself: That is exactly what I want to do.  Linus vetoed
> it in October 2000.

Right. And I still think Linus is dead wrong here. IMVVHO.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[David S. Miller]

   From: Jeff Garzik <garzik@havoc.gtf.org>
   Date: Thu, 31 Jan 2002 23:48:45 -0500

   I agree with Linus we need metadata files (driver.conf), not
   yanking all that info out of the source code.

I'm perfectly fine with this too.

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[David S. Miller]

   From: Keith Owens <kaos@ocs.com.au>
   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.

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Keith Owens]

On Thu, 31 Jan 2002 22:01:21 -0800 (PST), 
"David S. Miller" <davem@redhat.com> wrote:
>   From: Keith Owens <kaos@ocs.com.au>
>   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.

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[David S. Miller]

   From: Keith Owens <kaos@ocs.com.au>
   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.

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Keith Owens]

On Thu, 31 Jan 2002 22:26:43 -0800 (PST), 
"David S. Miller" <davem@redhat.com> 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.

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Alan Cox]

> 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

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Jeff Garzik]

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

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Petr Vandrovec]

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
						vandrove@vc.cvut.cz

[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);

VESA Anybody out there

[Martin Dalecki]

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?

Re: VESA Anybody out there

[Davidovac Zoran]

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 <dalecki@evision-ventures.com>
> To: linux-kernel@vger.kernel.org
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: VESA Anybody out there

[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.

Re: VESA Anybody out there

[Thomas Capricelli]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: VESA Anybody out there

[Martin Dalecki]

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*.

Re: VESA Anybody out there

[Sergey S. Kostyliov]

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 <rathamahata@php4.ru>

Re: VESA Anybody out there

[Anton Altaparmakov]

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/

Re: VESA Anybody out there

[Petr Baudis]

Dear diary, on Fri, Feb 01, 2002 at 04:29:39PM CET, I got a letter, where
Martin Dalecki <dalecki@evision-ventures.com> 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/

Re: VESA Anybody out there

[The Candyman]

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.

Re: VESA Anybody out there

[Andreas Happe]

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.

Re: VESA Anybody out there

[Martin Dalecki]

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.

Re: VESA Anybody out there

[Pavel Machek]

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 mj@ucw.cz, 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

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[David Woodhouse]

vandrove@vc.cvut.cz 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

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Horst von Brand]

Jeff Garzik <garzik@havoc.gtf.org> said:
> 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...

Not _one_ central file telling everything, please! Let each driver declare
what it needs and provides, and sort it out from there. Even better would
be something like "depmod -a" that doesn't need explicit dependencies
declared, but that looks like too much hair IMVHO.

Why do I have this uneasy feeling it would somehow overlap with CML2's job?
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Jeff Garzik]

Horst von Brand wrote:
> 
> Jeff Garzik <garzik@havoc.gtf.org> said:
> > 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...
> 
> Not _one_ central file telling everything, please! Let each driver declare
> what it needs and provides, and sort it out from there.

"driver.conf" is a reference is a metadata file per driver or
per-subdirectory, not one big file.

Linus suggested this back in December.  See the links I posted.


> Why do I have this uneasy feeling it would somehow overlap with CML2's job?

It could either (a) generate CML2 or (b) make CML2 irrelevant, depending
on the implementation.

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Alan Cox]

>    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?

The crc32 dependancy deduction is a seperate problem to asking excessive
questions. That is down to the makefiles. If its hard to express then
presumably Rules.make isnt yet perfect.

Does kbuild make it all simpler ?

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Rob Landley]

On Thursday 31 January 2002 07:30 pm, David S. Miller wrote:
>    From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>    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?

I thought this was the sort of reason CML2 was invented?

Rob

Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

[Jeff Garzik]

On Fri, Feb 01, 2002 at 02:37:30PM -0500, Rob Landley wrote:
> On Thursday 31 January 2002 07:30 pm, David S. Miller wrote:
> >    From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> >    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?
> 
> I thought this was the sort of reason CML2 was invented?

This case is handled now, CML2 is not needed for this.

RTFS

	Jeff, allowing himself to be trolled