|
|
Subscribe / Log in / New account

A summary of 2.6.12 API changes

The 2.6.12 kernel was over three months in the making; for all the talk of how the BitKeeper episode slowed down development, this kernel did not actually take much longer than its predecessor. The 2.6.11 process, from December 24 to March 2, took almost as long. Certainly there has been time to break a few interfaces in the kernel, though this cycle was not as disruptive as some of those which came before. Here is a list of internal kernel API changes in 2.6.12 which are most likely to be noticed by developers of external modules - drivers and such.

  • cancel_rearming_delayed_work() was added to the workqueue API.

  • The timeout value passed to usb_bulk_msg() and usb_control_msg() is now expressed in milliseconds instead of jiffies.

  • An interrupt-disabling spinlock is used in the rwsem implementation. It was never correct to call one of the variants of down_read() or down_write() with interrupts disabled, but it is even less correct now.

  • The fields in the net_device structure have been rearranged, which will break binary-only drivers.

  • kref_put() now returns an int value: nonzero if the kref was actually released.

  • kobject_add() and kobject_del() no longer generate hotplug events. If you need these events, you must call kobject_hotplug() explicitly. The wrapper functions kobject_register() and kobject_unregister() do still generate hotplug events.

  • kobj_map() no longer takes a subsystem argument; instead, it needs a pointer to a semaphore which it can use for mutual exclusion.

  • A new function, sysfs_chmod_file(), allows permissions to be changed on existing sysfs attributes.

  • There is a new generic sort() function which should be used in preference to creating yet another implementation.

  • A new attribute (__nocast) is being used with sparse to disable a number of implicit casts and find probable bugs.

  • io_remap_page_range() is now deprecated; use io_remap_pfn_range() instead.

  • A set of functions has been added to work with big-endian I/O memory.

  • synchronize_kernel() is deprecated. Callers should instead use either synchronize_sched() (to verify that all processors have quiesced) or synchronize_rcu() (to verify that all processors have exited RCU critical sections).

  • The flag argument to blk_queue_ordered() has changed to indicate how ordered writes are handled by the device. Possible values are QUEUE_ORDERED_NONE (ordering is not possible), QUEUE_ORDERED_TAG (ordering is forced with request tags), and QUEUE_ORDERED_FLUSH (ordering is done with explicit flush commands). For the last case, the request queue has two new methods, prepare_flush_fn() and end_flush_fn(), which are called before and after a barrier request.

  • A new function, valid_signal(), can (and should) be used to test whether signal numbers from user space are valid.

  • The Developers Certificate of Origin, the document acknowledged by all those "Signed-off-by:" headers, has changed. The new version adds a clause noting that contributions - and the information that goes with them - are public information which can be redistributed.

This list will be folded into the 2.6 API changes page when your editor returns from vacation.


to post comments

A summary of 2.6.12 API changes

Posted Jun 30, 2005 6:52 UTC (Thu) by henriksorensen (guest, #6313) [Link]

Thanks for an excellent summary.
Would it be possible for you to also cover new CONFIG options ?

Henrik

Another change

Posted Jun 30, 2005 16:36 UTC (Thu) by Ross (guest, #4065) [Link]

I ran into some trouble with out-of-tree drivers and changes from 2.6.11.11
to 2.6.12. There was an "id" member deleted from some I2C structure or
something similar. Just deleting the assignments and accesses was enough to
make it work... didn't find much on Google about it.

Sorry to be so non-specific but I don't have access to the box at the moment.

A summary of 2.6.12 API changes

Posted Jul 1, 2005 20:16 UTC (Fri) by roelofs (guest, #2599) [Link]

...for all the talk of how the BitKeeper episode slowed down development, this kernel did not actually take much longer than its predecessor.

I suspect most people would consider a 50% increase to be a fairly significant delay--at least, assuming 2.6.11's two months and a week was typical and 2.6.12's three months and two weeks was not. (I generally don't pay that much attention to kernel release intervals unless I need a specific fix or LWN brings it to my attention. :-) )

Not that I'm complaining, of course--considering what got done in that extra month-plus, I think it was time very well spent. And certainly the delay could have been much longer, which I guess was probably the point of the quoted comment...

Greg


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds