Uwe Bonnes asked: why are the IDE chipset support
driver not modularized? Is there anything fundamental that inhibits using
these drivers as a modules?
Steven Walter replied that "ATA/IDE/MFM/RLL
support" was a tristate option, and explained, If
you select that as a module, then all the chipsets you select for support
later will be compiled into one large module.
. But he warned that
compiling IDE support as a module was probably a bad idea, since it would
be impossible to mount root a partition on an IDE disk.
Artur Frysiak disagreed and said, If
you use initrd and load ide-mod, ide-probe-mod and ide-disk modules
on it then you may mount yours root partition.
He posted
a link
to geninitrd to help with this. Tomasz Koczko posted a link to bsp, saying,
This is ~25KB statically linked shell like
program/processor with loading modules, initialize RAID abilities for using
only inside initrd.
The thread ended there.
Alex Buell posted a short patch against 2.2.19 and explained, I have a patch here that fixes an annoying bug in the cg14
framebuffer driver on sparc32 platforms. The bug is when it never switches
off the cursor before going into X11 mode, so you get an 'orrible cursor
overlaying whatever you've got on the screen, in the same position as the
consoles. Switching to any console and back to the X11 display, the cursor
overlays the last position the cursor was in on the console. On investigating,
discovered that the cg14 framebuffer doesn't switch off the cursor!
David S. Miller thanked Alex for finding and squashing that bug, and announced
that he'd already put the fix in his Sparc 2.2 and 2.4 trees. Alex asked
how David had ported the patch to 2.4, but the discussion skewed off into
compiler issues, and the thread died.
Paul G. Allen announced:
For those interested, I have run the kernel (2.4.2-2) through a program and generated extensive HTML reports including call trees, function and data declarations, source code, and metrics. I plan to upgrade this to the latest kernel and keep it up to date (as much as possible :), but I am a) working with a kernel that I know currently runs on my dual Athlon, and b) wanted to test this out and run it by the two lists first.
My bandwisth is currently limited (cable modem), but if it's decided that I'll keep this available, I will upload it to a web server with a couple T1's avalable (or maybe I will use one of our companies servers on a DS3 or greater).
The URL is:
After a couple of notes from people who were having problems, and Paul
correcting them, and posting responses, everything seemed to be working well.
The thread ended when Paul stated, Please, no
more wgets on my poor limited bandwidth (256Kbit uplink) web server. Next
week I will have a fatter pipe and you can D/L the whole dir if you
want. (Though it would be better if you let me compress it and put it on a
ftp server).
In postscript, it should be noted that the web site has moved, and is now located at:
http://www2.randomlogic.com/linuxkernel/index.html
The web site has also been updated to measure metrics on the 2.4.7 kernel as well.
Frank Fiene remembered seeing a graphical representation of
the kernel sources, and asked where to find it. Jan-Benedict Glaw
replied, You probably mean the
LGP (Linux Graph Project) by Rusty,
but he didn't know
where to find it. Gordon Fraser also replied to Frank, saying,
This is what you're looking for: http://fcgp.sourceforge.net/.
Frank went to the site and it was exactly what he wanted. But he said:
lgp version 2.4.0a works fine but the latest 2.5.1 does not. Compile error is
data2ps.o: In function `d2p_draw_line':
/home/ffiene/docs/lgp-2.5.1/data2ps.c:180: undefined reference to `cos'
/home/ffiene/docs/lgp-2.5.1/data2ps.c:181: undefined reference to `sin'.The files data2ps.c in both versions have not man different lines of code, so i didn't find the error.
Several folks (including Frank) then replied with the solution. As
Gordon put it, Try adding -lm to the CFLAGS in
the Makefile, this should do the trick.
End of thread.
Hugh Dickins said, do_wp_page() COW breaking is
now very slightly unsafe. Please don't ask me to provide a test case! but
the pte_same() check after regetting page_table_lock is not quite enough
to guarantee that the old_page was not reaped, reused for something else,
copy_cow_paged while containing that other data, freed and then reused for
precisely its original pte.
Linus Torvalds replied:
Oh, but it is.
We do hold the MM semaphore over the whole sequence, so there's no way the page table entry can be replaced by anything else than a non-present one (ie vmscan can swap it out, but nothing can swap it in because of the lock).
So yes, we may copy data that is "garbage", but re-testing the page table will make sure that if it was garbage we will never use it.
Hugh replied, Sorry for being dense, but I still
don't get it. I thought the down_read on mmap_sem is permitting concurrent
faults by other users of the address space (but excluding structural changes
to the address space)? and we haven't locked the page itself, and we've
temporarily dropped the page_table_lock. I just don't see what lock prevents
the page from being refaulted in.
Linus said:
Ehh, you're right. But you're still wrong, I think.
Because we hold the mm semaphore, nobody can change the mapping on us.
Which means that even if we first page somthing out and page something else in to the same page, that "something else" has to be the same thing. See?
Hugh posted a patch and said, Sure, I agree with
you on that, but it doesn't let us off the hook. This isn't necessarily the
first reuse of that page: after paging it out and freeing it, it may have
got allocated to some other purpose and freed again, and then reassigned to
the original use. And while it held the data from that intermediate use, we
may have done the copy_cow_page from old_page to new_page, and now we come
along and substitute this corrupt new_page for the good old_page.
Linus said, Ok, you've convinced me. Thanks for
showing me the error of my ways. Fixed.
End Of Thread (tm).
An anonymous poster asked if it would be legal to implement a closed-source
driver that would overwrite existing function pointers in the run-time Linux
kernel. The poster argued that since no kernel source code was modified, there
would be no obligation to release the driver's sources. Alan Cox replied,
You modify a GPL program and link with it. I'd say
its quite clear you are linking.
Richard B. Johnson also said to
the original poster:
Not only is the wording of GPL, but also its intentions important. If the intentions of the GPL are to help promote the free flow of ideas, and to show explicitly how some software is implemented, then any attempt to obscure, disguise or hide the implementation details is contrary to its intent.
It is my opinion that any software that is provided without its source-code is contrary to the intent of GPL. However, I'm sure that there are lawyers who will disagree.
We already have so-called "proprietary" code being included into the kernel. This started with "harmless" bits of binary which is uploaded into the hardware when some drivers are installed. Including such binary is also contrary to GPL, but without this secret goo, the hardware won't run.
This exception to GPL, in my opinion, opened the door to future corruption and exploitation. Time will tell.
Now, if your code attacks and destroys, replaces, or otherwise modifies a kernel, I think that's fine as long as the source-code is provided. You can even develop modules that are designed to do harm.
Rob Landley also said to the original poster:
You mean like writing to /dev/kmem or some such?
Good luck. Deep, evil black magic. According to Linus you can basically do anything you want from user space (including loading binary kernel modules at run-time), but the only way any sort of hook to make intrusive binary-only changes EASIER is over Linus's dead body. That's my understanding of it, anyway.
It's going to break going from 2.4.7 to 2.4.8. And then it's going to break again going from 2.4.8 to 2.4.9. And anybody who has a kernel with your binary-only gorp in it won't even be LISTENED to if they submit bug reports to this list with that stuff loaded. They will be sent back to you for all support including stuff that IS a problem with the rest of the kernel.
Drew Bertola wrote:
To celebrate the 10 years since Linus posted the first announcement about his "hobby", svlug and sbay.org are hosting a Picnic/BBQ on Saturday, Aug. 25th in Sunnyvale, CA, USA.
I'm posting because many of you may be in the Bay Area that weekend for Linux World or IDC (both the following week) and we don't want you to miss out. Everyone is welcome to attend. Their will be free food and drinks* for everyone who RSVPs.
T-shirts are being sold to fund the event. Email me at drew@linux10.org if you'd like to purchase one. (see: http://linux10.org/images/frontshirt.jpg ).
If you are in the area that weekend, please rsvp as soon as possible at: http://linux10.org/rsvp/ and if you need transportation, check out the ride-board at: http://linux10.org/ride_board/
Any questions? Please email me off-list at drew@linux10.org.
Allan Sandfeld Jensen said:
I've solved a long standing problem with using an extended mouse over the ps/2 port on a thinkpad. (search deja, I found bugreports dating back to 1998, all unanswered)
I discovered there is a "smart" device called a trackpoint controller, that accumulates movement from both the trackpoints and the external mouse. Provided it understands the external mouse! (it only understand standard mice) A quick hack is disabling the trackpoint controller by sending 0xe2 0x4e, but a more general solution would be to write a linux driver that autodetected a trackpoint controller with external mouse and disabled it. In that way it would be transparant to userspace drivers.
The easiest for my would be writing it into pc_keyb.c but that's not appropiate. So where should I place the driver? If I want advanced functionality, where I instead demultiplexes the trackpoint and the external mouse into a /dev/psaux1 and -2, I need to take over the aux interrupthandler. Otherwise I can just speak through the standard psaux.
And what of the new input-class, should all inputdevices eventually move over there, or just USB?
Thomas Hood said about autodetecting and disabling trackpoint
controllers with external mice, The
TrackPoint can be auto-disabled using tools like PS2.EXE and
tpctl too. Unfortunately, the current Linux drivers do not handle
wheel data correctly. Vojtech Pavlik's new input drivers (the ones
that are already used for USB HIDs) do handle wheel data correctly,
but these will only go into Linux 2.5 I'm told. More info at my site: http://panopticon.csustan.edu/thood/tp600lnx.htm#secmouse
Thomas added in general, If you want to
hack the existing drivers, perhaps you should get in touch will
Till Straumann, who has written TrackPoint utilities for Linux: http://www-hft.ee.TU-Berlin.DE/~strauman/tp4utils/
End of thread.
