Re: ruby for recent 2.6.1 & 2.6.2-rcX kernels?

[James S. <jsi...@in...>]

> Hi James,
> 
> at first a little bit rant may be :-)
> <rant>
> James, why don't you work step by step?
> why don't you use a stable? working code base?
> IMO you start a lot of new things before completing older work items.
> Why don't you use the Aivils codebase, polish it up, and add new features
> one by one, convert old features to new interfaces one by one, without
> breaking stuff.
> Currently (IMHO ) in your tree bugfixing, development/testing is done mostly
> in your head (with no, or with verry small user testing ), if you were using
> Aivils codebase (a working codebase) you would have a much wider
> testing and i think this could help.
> </rant> 

I played with both trees. The only reason for not syncing is because I 
knew the framebuffer code would change alot. Also I knew my fbdev tree 
would be different from the one linus would recieve. BTW I will start 
merging the fbdev over teh next several days.
 
> > Because sysfs mounts the pci space and you can configure your pci 
> > hardware in userland :-) Try a 2.6.X kernel and do a 
> 
> i'm running 2.6 for the last 2 months or so
> /* and i didn't  looked much in sysfs */
> 
> but do you mean that one can already use sysfs
> to tel the kernel to ignore the mentioned XFree commands ?

I have a feeling you can. I will talk to Patrick about how to do this.


> > > > > variable vc count) 
> > > > 
> > > > The only reason for this is to have many dummycons. With sysfs this
> > can go
> > > 
> > > what do you mean by this ?
> > > IMO we have a limit of 64 vc's,
> > > if (the case with the bk tree) vc_count is fixed to 16
> > > we have a maximum of 64/16 = 4 consoles (fb/dummy)
> > > which IMO is pretty limiting 
> > > ( e.g. only 2 Matrox G200/ Gx50 DH or single G200/G4500 MMS QH)
> > > whereas in combination with LTSP i could imagine a 10/16/20 headed box
> > > which works relatively responsible
> > >
> > > vc_count also gives you possiblity to limit the number of allocated vc's
> > > for fb consoles (IIRC except the one that takes over vga)
> > > 
> > > if the maximum 64 is really a hardlimit, there should be a way 
> > > to change vc_count in order to increase the number of consoles
> > 
> > I agree that 64 is way to small of a limit. We need to correct the tty
> > layer 
> > to deal with this limit. In fact I think 64 heads is too small of a limit.
> > 
> > I like to see it be dynamic. Unfortunely the problem is the serial ttys 
> > use the same major number range as VTs. How can we get around this? Well I
> > 
> > have a idea on how to ask about this dealing with udev.
> 
> you have in mind dinamic minor allocation  wjhich is supposed
> to go in 2.7 ?
> 
> > > and yes, there are already user(s) with 4 X servers running
> > > ( i know one of them :-) )
> > > 
> > > oh
> > > and without /proc/bus/console keyboard configuration
> > > this means only 2 displays/heads in case usb multimedia keyboards
> > > are used
> > 
> > Is this the USB keyboards showing up as two seperate devices problem.
> 
> yes,
> AFAIK multimedia keys are always using interface1
> it would be great to remap all interface1 kbd's to the corresponding
> interface0 kbd's, but just ignoring the interface1 kbd's when 
> building vt - keyboard pairs would help too
> 
> we probably could also ignore ir-keyboards in the same way
> just don't bind kbd's with PHYS == "pci-......." when building the pairs
>  
> > > > away. Also this breaks some of the SysV console ioctls :-(
> > > 
> > > isn't it fixable ? how bad is it ?
> > 
> > Pretty yucky. Alot fo legacy software would break.
> > 
> > > does this mean that ruby will stay only linux-2.8/ 3.0 code
> > > or do you plan to change the ABI in linux-2.6 ?
> > 
> > Ruby will be 2.8/3.0 code.
> 
> > > let's all hope Linus wil accept it :-)
> > 
> > I spoke to linus about the patches. he will accept the fbdev patches as 
> > long as they are broken into smaller pieces.
> 
> that's great :-)
> 
> best,
> svetljo
> 
>