Ok, I've merged stuff from more people, and 2.5.44 is out there. We're
getting closer, folks.
And for the ext 8 days (starting _now_) it is totally unnecessary to try
to send me patches or cc me on the discussions about what needs to be
merged or not. I won't read it, and when I get back I will likely just
flush the whole inbox, since there's no way I can try to catch up _and_
try to merge some final pieces before the feature freeze at the same time.
I've asked various people to act as merge-points for me while I'm gone,
and to avoid having them mailbombed or pressured into accepting stuff they
don't really want to, I won't even tell who they are ;)
Anyway, the 2.5.44 patches are all over the map, see for yourself in the
appended changelog.
I repeat: while I'm gone, please use linux-kernel as a central point for
discussion, and I assume that all the normal suspects will maintain their
own set of fixes for it. Don't fill my inbox,
Linus
----
Summary of changes from v2.5.43 to v2.5.44
============================================
<[email protected]>:
o cpqarray IDA_LOCK compile fix
<[email protected]>:
o 2.5.43: cpqarray compile fix
Adam Belay <[email protected]>:
o PnP Rewrite V0.9 - 2.5.43
William Adamson <[email protected]>:
o kNFSd: NFSv4 patch for new setclientid, setclientid_confirm
Angus Sawyer <[email protected]>:
o Fix for raid1 against 2.5.43
Cort Dougan <[email protected]>:
o PPC32: Fixes for Force PowerCore boards
Dave Jones <[email protected]>:
o net/ipv4/udp.c: Log short packets more verbosely
o updated MAINTAINERS
o gscd printk's wrong type
o CONFIG_DEBUG_STACKOVERFLOW
o bluesmoke incorrectly calls function twice
o Remove duplicate config.help
o Elan BIOS quirk workaround
o Silence epat init
o Missing checks in sis drm
o ens1370 uses wrong printk type
o Typos
o Make sbpcd look more like 2.5 driver
o Add printk levels
o 64bit fixes for smbfs
o extern inline -> static inline
o Correct indentation on x86-64 MTRR driver
Dan Streetman <[email protected]>:
o uhci: slight docs update
o uhci: remove qh from qh->list
o change devio-disconnect no-driver error code
o uhci interrupt resubmit fixes
Dipankar Sarma <[email protected]>:
o RCU helper patchset 1/2
o RCU helper patchset 2/2
Jeb Cramer <[email protected]>:
o e1000 update 1 - 10
<[email protected]>:
o aio updates
Alexey Kuznetsov <[email protected]>:
o [NET]: Prepare for zerocopy NFS and IPSEC
o [IPv4]: More output path work
Mark Haverkamp <[email protected]>:
o 2.5.43 aacraid driver
Randy Dunlap <[email protected]>:
o 2.5.42 HID-BP menu
<[email protected]>:
o drivers/net/eepro100.c: simplify wait_for_cmd_done(), better errors
o drivers/net/eepro100.c: only set priv->last_rx_time if we did work
o drivers/net/eepro100.c: mask the interrupt and do a small delay on
close()
<[email protected]>:
o sctp: Fixes a couple of sctp_peeloff() issues
o sctp: VTAG checks for ABORT & SHUTDOWN_COMPLETE chunks
(ardelle.fan)
o sctp: Fixes Bug#623286 - zero vtag in SHUTDOWN_COMPLETE chunk
(samudrala)
o sctp: Fixes a bug in the calculation of highest new tsn in sack
Steven Whitehouse <[email protected]>:
o [DECNET]: Update to support timeouts
Adrian Bunk <[email protected]>:
o don't #include tqueue.h in rio_linux.c
Alexander Viro <[email protected]>:
o infrastructure
o cdrom helpers
o compile fixes
o pd.c cleaned up
o pcd.c cleaned up
o pf.c cleaned up
o probes
o ide.c cleaned up
o md.c
o mfmhd.c
o loop.c
o sr.c
o sd.c
o ftl.c
o aztcd.c
o cdu31a.c
o cm206.c
o gscd.c
o mcd.c
o mcdx.c
o optcd.c
o sbpcd.c
o sjcd.c
o sonycd535.c
o acsi.c
o ubd
o cciss
o umem
o swim_iop
o swim3
o acorn floppy
o amiga floppy
o atari floppy
o DAC960
o cpqarray
o floppy
o i2o
o old methods removal
o compile fixes
o jsfd converted to use of private queue
o nbd converted to private queue
o stram switched to private queue
Alexey Kuznetsov <[email protected]>:
o [TCP]: Handle passive resets correctly in SYN-RECV
o [IPv4]: More output path work
Andi Kleen <[email protected]>:
o x86-64 updates for 2.5.43
o add linux/ioctl32.h header for 2.5.43
Andrew Morton <[email protected]>:
o ia32 uniprocessor compile fixes
o fix the build for CONFIG_MD
o disable 64-bit sector_t on ppc32
o fix oops in reiserfs_ioctl()
o fix a VM lockup
o simple_rename() link count fix
o make filemap_sync static
o don't allocate an extra page in vmalloc
o don't make writers wait on their writeback in page reclaim
o uninline somethings in fs/*.c
o uninline the ia32 highmem functions
o ramdisk fix
o 3com driver fix
Anton Blanchard <[email protected]>:
o ppc64: fix dump_stack
o ppc64: sigcontext_struct -> sigcontext, from Stephen Rothwell
o ppc64: updates for Ingo's signal changes
o ppc64: add might_sleep to semaphore code
o ppc64: move pci_device_to_OF_node so radeonfb can get at it
o ppc64: remove pciconfig_iobase, its broken when IO resources are >
4GB
o ppc64: update in_atomic definition
o ppc64: only enable eeh if something supports it
o ppc64: dont mark openpic_setup_lock as __initdata, we need it for
cpu add
o ppc64: clean up exception table code, we werent taking the
modlist_lock
o ppc64: Only do an exception check if an 0x380 ends up in
do_page_fault
o ppc64: some xmon fixes for SLB faults, also store breakpoint
address in a long
o ppc64: local_irq_restore was missing a gcc barrier
o ppc64: reduce stack usage of prom_instantiate_rtas
o ppc64: update defconfig
o ppc64: early printk support from Todd Inglett
o ppc64: merge status indicator update from 2.4
o ppc64: use generic debugger hooks in smp_call_function, busy loop
instead of udelay
o ppc64: disable ancient select syscalls
o ppc64: merge some xmon updates from ppc32
o ppc64: update to match recent kbuild changes
o ppc64: ipc fixes from Peter Bergner and 64bit types updates from
2.4
o ppc64: fix Makefile so it actually works
o ppc64: remove 64bit old uname syscall
o ppc64: limit NR_CPUS to 32 temporarily, need to hunt down the 500kB
of bloat it causes
o ppc64: Handle some broken ioctls that do _IO(,,sizeof(struct foo))
instead of just struct foo
o ppc64: Dont allow us to recursively call printk, spotted by Milton
Miller
o ppc64: fix an IPC bug
o ppc64: Fix for copy_tofrom_user from Paul Mackerras
o ppc64: Fix semctl return code, also msgrcv/msgsnd fixes courtesy of
Andi
o ppc64: fix from ppc32 for sugsuspend bug
o ppc64: Fix pgd_index overflow in free_pgtables and move stack up to
2^41
o ppc64: fix ptrace GETREGS/SETREGS
o ppc64: add missing include
o AIO
o ppc64: defconfig update
Arnaldo Carvalho de Melo <[email protected]>:
o ipv4: udp seq_file support: produce only one record per seq_show
o ipv4: make arp seq_file show method only produce one record per
call
o ipv4: remove the hack, using seq->private to hold state
o ipv4: remove the hack, make udp seq_file functions use
seq->private
o Add support for JTEC FA8101 USB to Ethernet device
Benjamin LaHaise <[email protected]>:
o get rid of a double free in aio.c introduced by a merge mistake
o adds more aio exports for filesystems
Christoph Hellwig <[email protected]>:
o make LSM register functions GPLonly exports
o remove LSM file_llseek hook
o XFS: fix a makefile comment
o kNFSd: minor knfsd cleanups
o kNFSd: switch knfsd to vfs_read/vfs_write
o XFS: add synch I/O entry points
Daisy Chang <[email protected]>:
o sctp: Fix bug 611919 - should ignore the cwnd value for fast
retransmit
Dan Cox <[email protected]>:
o PPC32: Add support for the SBS Palomar 4 embedded board
David Brownell <[email protected]>:
o LDM and driver binding
o one liner, anti-oops
David Howells <[email protected]>:
o do_generic_file_read / readahead adjustments
o missing put in AFS client
David S. Miller <[email protected]>:
o [NET]: Kill final traces of csum_partial_copy_fromuser
o [SPARC64]: On broken cheetah, enable p-cache around large copies
o [NET]: Cleanup now that sockfd_lookup/sockfd_put are exported
o arch/sparc64/solaris/socket.c: Kill more sockfd_{lookup,put}
redefinitions
o net/ipv4/udp.c: proto sendpage returns int not size_t
o net/bluetooth/bnep/sock.c: Kill another sockfd_lookup
re-implementation
o net/ipv4/ip_proc.c: Fix 64-bit warnings
o arch/sparc64/kernel/time.c: Include linux/profile.h
o arch/sparc/kernel/time.c: Include linux/profile.h
o [SPARC]: Export memchr
o [NET]: Apply missed parts of csum_partial_copy killing patch
o arch/{i386,sh}/lib/Makefile: Kill old-checksum.o
o [SPARC]: Add sys_lookup_dcookie
o drivers/net/3c59x.c: Do not forget to set AddUDPChksum
o arch/sparc{,64}/vmlinux.lds.S: Update for init section name changes
o net/ipv6/mcast.c: Remove unused variable addr_type
o [SPARC64]: Disable old cheetah pcache optimization
o De-bloat linux/fs/aio.c
o Fix scsi breakage
o Fix scsi OOPS on bootup
Frank Davis <[email protected]>:
o [IPV4]: Fix CONFIG_NET_FASTROUTE compile
o drivers/block/xd.c compile
Greg Kroah-Hartman <[email protected]>:
o Cset exclude: [email protected]|ChangeSet|20021015071026|11647
o driver core: fix up merge mess
o USB: fix problem with removing a USB root hub
Hideaki Yoshifuji <[email protected]>:
o net/ipv6/mcast.c: Fix source address selection of MLD Report/Done
messages
o [IPV6]: Several MLD fixes
James Bottomley <jejb@mulgrave.(none)>:
o [SCSI] bring block TCQ helpers into line with new TCQ code
o [SCSI 53c700] update with new TCQ code
o [SCSI sd] make cache probe sensitive to unsupported mode page
o [SCSI sd] correct wrong prink statement
Jens Axboe <[email protected]>:
o sym2 get host
o make SCSI understand REQ_BLOCK_PC
o make calling scsi_cmd_ioctl() part of generic cdrom_ioctl
o block cleanups
Johannes Erdfelt <[email protected]>:
o 2.5 uhci remove correct proc directory
o 2.5 uhci remove urb from lists on error
o 2.5 uhci proc path
o 2.5 uhci breadth first traversal for low speed
o 2.5 uhci control and interrupt queuing
Jon Grimm <[email protected]>:
o sctp: in sendmsg: on err, only free asoc if init failed. (jgrimm)
o sctp: Fix restart address add prevention logic (jgrimm)
o sctp: Various invalid address check fixes. (jgrimm)
o sctp: Fix small data can bypass pending rtx data bug. (jgrimm)
Kai Germaschewski <[email protected]>:
o Move kallsyms section next to other read-only sections
o Clean up arch/i386/vmlinux.lds.S
o kbuild: Add build dep for UML
o kbuild: More cleaning work
o ISDN: new xmit handling for ISDN net interfaces
o ISDN: Move generic xmit/recv handling into isdn_net_lib.c
o ISDN: Unclutter isdn_net.h
o ISDN/PPP: Adapt sync-PPP
o ISDN/PPP: Rename struct 'ippp_struct' to 'struct ipppd'
o ISDN/PPP: Move state from ipppd to isdn_net_dev/isdn_net_local
o ISDN/PPP: Move CCP related stuff into isdn_ppp_ccp.c
o ISDN: Named initializers for isdn_bsdcomp.c
o ISDN: Bug fixes for the isdnloop driver
o ISDN/PPP: Remove bogus header handling
o ISDN/PPP: PPP header cleanups
o ISDN/PPP: CCP flags handling
o ISDN/PPP: Move rest of CCP reset handling into isdn_ppp_ccp.c
o ISDN: Start refcounting for per-ipppd data
o ISDN/PPP: Reference struct ipppd directly
o ISDN/PPP: dynamically allocate struct ipppd, further cleanups
o ISDN/PPP: cosmetics
o ISDN/PPP: clean up ipppd_write() and ipppd_ioctl()
o kbuild: Speed up new "make clean/mrproper"
o kbuild: More "make clean" cosmetics
o kbuild: another "make clean" micro-optimization
o kbuild: Fix temporary hack
Linus Torvalds <[email protected]>:
o Fix IDE init order dependency problem, noted by Jens Axboe
o Make x86 UP "set_mb()" use a lighter barrier than doing a full
locked "xchg". It only needs a compiler barrier on UP.
o Make a polite version of BUG_ON() - WARN_ON() which doesn't kill
the machine.
o Fix up sym53c8xx driver for new scsi_host_hn_get() infrastructure.
Maksim Krasnyanskiy <[email protected]>:
o [NET]: Export sockfd_lookup
o Fix files that escaped CONFIG_BLUEZ_XXX -> CONFIG_BT_XXX cleanup
o Users must have CAP_NET_ADMIN capability in order to create
o Just like many other parts of the kernel Bluetooth code was abusing
typedefs for non opaque objects. This changeset cleans up L2CAP
code and headers. In addition it optimizes sendmsg for L2CAP
sockets.
o Just like many other parts of the kernel Bluetooth code was abusing
typedefs for non opaque objects. This Changeset cleanups Bluetoth
HCI code and headers.
o Consistent naming for Bluetooth HCI events, commands and parameters
o Correct RFCOMM modem status implementation
Marcel Holtmann <[email protected]>:
o Use kernel crc32 for BlueZ BNEP
Martin Diehl <[email protected]>:
o usbtest updates
Matt Domsch <[email protected]>:
o EDD: x86 BIOS Enhanced Disk Drive support
Matthew Dharm <[email protected]>:
o Fixes to CB/CBI and compilation problems
Matthew Wilcox <[email protected]>:
o Fix file locking yield()
o Allow compilation with -ffunction-sections
Mike Anderson <[email protected]>:
o scsi host cleanup 1/3 (base) (corrected)
o scsi host cleanup 2/3 (mid lvl changes)
o scsi host cleanup 3/3 (driver changes)
o scsi_debug new scan fix
Neil Brown <[email protected]>:
o kNFSd: Reorganise rpc program version management
o kNFSd: Export news symbols in sunrpc
o kNFSd: Fix problems when releasing cache item
o kNFSd: Change names of some exported functions
o kNFSd: Unregister export caches in proper order
o md: Register mergeable function for linear so requests
don't cross device boundries
Patrick Mansfield <[email protected]>:
o Re: [PATCH] SCSI-2 LUN setting consolidation
Patrick Mochel <[email protected]>:
o driver model: make device_unregister() only mark device as !present
o driver model: make driverfs an implicit initcall
o driver model: change bus refcounting scheme to match devices'
o driver model: make driver refcounting similar to devices'
o driver model: change class reference counting to be like devices'
o driver model: replace rwlock in struct bus_type with a rwsem
o driver model: make sure device has driver when we add it to the
class
o driver model: simplify device/driver binding
o driver model: make sure we call device_unregister() and not
put_device() when removing system and platform devices.
o driver model: add per-class rwsem and protect list accesses with it
o driver model: add struct device_driver::shutdown() method and
device_present() helper
o driver model: protect drivers' device list accesses with bus's
rwsem
o driver model: clean up bus_for_each_{dev,drv}
o driver model: introduce device_sem to protect global device list
instead of device_lock
o driver model: power management/shutdown cleanup
o driver model: change struct device::present to enumerated value
with multiple states
o driver model (pci): change call of remove_driver to
driver_unregister
o driver model (scsi): change calls of remove_driver() to
driver_unregister()
o driver model(usb): change calls of remove_driver() to
driver_unregister()
o driver model (arm): change calls of remove_driver() to
driver_unregister()
o driver model: use list_for_each_safe() when removing devices from a
driver
o add sysfs filesystem, maintaining the driverfs revision history
o sysfs: modify enough names to get it build and link w/o conflicts
o sysfs: copy driverfs_fs.h to sysfs.h
o sysfs: search replace to convert remaining names from driverfs* to
sysfs*
o sysfs: clean up a couple of remaining driverfs references in
sysfs.h
o sysfs: do kern_mount() on init
o sysfs: copy driverfs documentation to be sysfs documentation
o driver model: make sure we only try to bind drivers to devices that
don't have a driver
o driver model: fix matching bug
o driver model: device removal
Paul Mackerras <[email protected]>:
o PPC32: make xchg take volatile *, remove duplicate xchg_u32 defn
o PPC32: export open/read/lseek/close for the sake of ALSA modules
o PPC32: Update boot wrapper Makefiles
o PPC32: fix a typo in mpc10x.h
o PPC32: Add some extra kernel debugging options
o PPC32: make do_div handle all 64 bits of the dividend (not just 32)
o PPC32: allow for host bridges that have a type field in the addr
word
Pete Zaitcev <[email protected]>:
o arch/sparc/boot/Makefile: Use libs-y
o [sparc] Use Kai's way to make asm_offsets.h
Randy Dunlap <[email protected]>:
o 2.5.43 IO APIC bit fields
o cpia fix for older compilers
o fix sysrq typos
Rob Radez <[email protected]>:
o [NET]: Remove final traces of csum_partial_copy
Romain Lievin <[email protected]>:
o char tipar driver minor update
Russell King <[email protected]>:
o set_task_state() UP memory barriers
o [ARM] time.c needs to include profile.h time.c handles the kernel
profiling, and references prof_buffer/ prof_len/prof_shift.
o [ARM] Convert ARM makefiles to new kbuild (Sam Ravnborg, Kai, rmk)
o [ARM] Kill compiler warning in decompressor
o [SERIAL] Fix missing parens in serial_core.h
o [ARM] Update ARM SA1111 pci_pool implementation 2.5.43 removed the
mem_flags parameter to pci_pool_create. The ARM SA1111
implementation needs to follow for the usbo hci implementation.
Sam Ravnborg <[email protected]>:
o kbuild: Distributed clean infrastructure
o scsi+aic7xxx: Utilise distributed clean List files to be deleted
during make clean where they are created
o drivers/{atm,char,pci,video,zorro}: ditributed clean Move list of
files to be deleted during make clean out where they are made.
host-progs files taken care of automagically
o drivers/net/hamradio/soundmodem: distributed clean Move list of
files out where it belongs
o kbuild: Distributed clean, misc
o docbook: Makefile cleanup
Scott Feldman <[email protected]>:
o e100 update 1 - 4
Stephen Lord <[email protected]>:
o XFS: busylist fixups
o XFS: fix previous change, the wrong xfs_alloc_mark_busy call was
removed
o XFS: fix byte ordering issues with earlier allocator fix
o XFS: fix xfs build on big endian architectures and cleanup
Stephen Rothwell <[email protected]>:
o [SPARC]: Move over to generic siginfo
o [SPARC]: arch specific copy_siginfo_to_user no longer needed
Steven Whitehouse <[email protected]>:
o [NET]: Kill old sklist_foo interfaces
Tim Hockin <[email protected]>:
o drivers/net/eepro100.c
o drivers/net/mii.c: only call netif_carrier_{on,off} if there is a
state change
o drivers/net/natsemi.c: init msg_enable in proper way
o drivers/net/eepro100.c: eliminate speedo_intrmask
Tom Rini <[email protected]>:
o PPC32: Update section names to .foo.text/.foo.data form
o PPC32: improve the memory size detection for PReP machines
Trond Myklebust <[email protected]>:
o Fix NFS typos in 2.5.43
o Fix 'long long' != u64 in NFSv4 debugging printks
Linus Torvalds wrote:
>
> Ok, I've merged stuff from more people, and 2.5.44 is out there. We're
> getting closer, folks.
>
> And for the ext 8 days (starting _now_) it is totally unnecessary to try
> to send me patches or cc me on the discussions about what needs to be
> merged or not. I won't read it, and when I get back I will likely just
> flush the whole inbox, since there's no way I can try to catch up _and_
> try to merge some final pieces before the feature freeze at the same time.
Perhaps this is good reason to delay the freeze for an additional 2 weeks or
so? I fail to see the necessity of rushing into a freeze, especially when
it seems obvious that people are trying to merge code which hasn't been
adequately tested. I think Hans Reiser and others have brought up valid
points that the freeze is happening too soon. I tend to agree, especially
looking back at the timetable surrounding 2.1.X development. Since I'm not
a contributor, I know my opinion doesn't count for much. Still, as a user
I think it is important not to write of new features just because they
didn't make the "arbitrary" freeze date. Again, I really don't see what
the rush is all about.
Just my .02 (US),
Nicholas
On Sat, Oct 19, 2002 at 08:41:18AM -0400, Nicholas Wourms wrote:
> Perhaps this is good reason to delay the freeze for an additional 2 weeks or
> so?
The same thing will happen. You will always get people rushing to get
their projects into the kernel just before a feature freeze no matter
what date gets set.
> Again, I really don't see what the rush is all about.
It's only a rush because that's what people with their features are doing.
The deadline of October 31 was set at the kernel summit on Ottawa around
the middle of June.
The whole idea of shortening the feature development time is to (hopefully)
shorten the stabilisation time after, and hopefully get 2.6 out earlier.
This then means 2.7 can open earlier.
Although this means that there will be fewer features between each stable
version, hopefully the stable version series will stabilise earlier.
Oh, and Oct 31st is one deadline we're trying not to miss. 8)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sat, 19 Oct 2002, Russell King wrote:
> Oh, and Oct 31st is one deadline we're trying not to miss. 8)
Well... Everybody here knows that the deadline is actually Crhismas Day
because OCT 31 == DEC 25.
... (or HEX 1F if you didn't catch it)
Nevermind. ;-)
Nicolas
On Sat, 19 Oct 2002, Nicholas Wourms wrote:
> Perhaps this is good reason to delay the freeze for an additional 2
> weeks or so? I fail to see the necessity of rushing into a freeze,
We're not rushing into a freeze. This date was agreed upon months ago.
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
Hi,
On Sat, 19 Oct 2002, Rik van Riel wrote:
> > Perhaps this is good reason to delay the freeze for an additional 2
> > weeks or so? I fail to see the necessity of rushing into a freeze,
>
> We're not rushing into a freeze. This date was agreed upon months ago.
But now would be a good time to recapitulate things which Linus might have
forgotten in the patching frenzy.
E.g. my configuration system is ready and still waiting to be merged.
bye, Roman
On Saturday 19 October 2002 07:41, Nicholas Wourms wrote:
> Linus Torvalds wrote:
> > Ok, I've merged stuff from more people, and 2.5.44 is out there. We're
> > getting closer, folks.
> >
> > And for the ext 8 days (starting _now_) it is totally unnecessary to try
> > to send me patches or cc me on the discussions about what needs to be
> > merged or not. I won't read it, and when I get back I will likely just
> > flush the whole inbox, since there's no way I can try to catch up _and_
> > try to merge some final pieces before the feature freeze at the same
> > time.
>
> Perhaps this is good reason to delay the freeze for an additional 2 weeks
> or so?
No, it isn't.
> I fail to see the necessity of rushing into a freeze,
The freeze date freeze was set and publicized more than 6 months ago. Define
"rushing".
> especially
> when it seems obvious that people are trying to merge code which hasn't
> been adequately tested.
There will always be code that's not ready before the freeze, and that won't
make it in. If this wasn't the case, there wouldn't be a need for a cutoff
date, would there? "Oh, development is over, there are no more interesting
new patches anywhere, we can all go home now." Doesn't happen.
Thawing the freeze won't help. As time approaches zero, effort approaches
infinity. (Remember college? How many papers did you hand in BEFORE they
were due?)
Meaningful deadlines have a nice motivating effect. Endless extensions are
just sloppy.
> I think Hans Reiser and others have brought up
> valid points that the freeze is happening too soon. I tend to agree,
> especially looking back at the timetable surrounding 2.1.X development.
2.1.X had a timetable?
(I mean, retroactively it had a time table, sure. But are you implying there
was some sort of planned schedule anybody paid attention to at the time? I
must have missed it. There was a lot of "we really mean it this time,
honestly", and "just this once, but don't do it again". But I don't remember
anybody actually paying attention after the first couple of times...)
> Since I'm not a contributor, I know my opinion doesn't count for much.
> Still, as a user I think it is important not to write of new features just
> because they didn't make the "arbitrary" freeze date. Again, I really
> don't see what the rush is all about.
Who says anything about writing off features? 3.0 isn't the end of the world.
The kernel team is trying to get it out now so people don't have to wait
another year or more to use the new features that have ALREADY gotten in.
With a snappy enough cycle time, it's possible to get this stable series into
the hands of users, open the next development branch, and have that one
stabilised and released before a traditional "two years plus" development
cycle like 2.3 or 2.1 would get to its FIRST dot-0 release (with the
obligatory brown paper bag bugs, since it's been so long since anybody
actually used the thing in production..).
Slowing down the development cycle does not speed the introduction of
features. Really.
Rob
On Sun, 20 Oct 2002 14:59:58 +0200 (CEST)
Roman Zippel <[email protected]> wrote:
> But now would be a good time to recapitulate things which Linus might have
> forgotten in the patching frenzy.
Yes. If we only consider new arch-independent features which are actively
being pushed at the moment and are feature complete, I get the following
(much stolen from Guilluame: thanks!):
- Build option for Linux Trace Toolkit (LTT) (Karim Yaghmour)
- Kernel Probes (Vamsi Krishna S)
- High resolution timers (George Anzinger, etc.)
- EVMS (Enterprise Volume Management System) (EVMS team)
- Device Mapper (lvm2) (Alasdair Kergon, Patrick Caulfield, Joe Thornber)
- New config system (Roman Zippel)
- In-kernel module loader (Rusty Russell)
- Unified boot/parameter support (Rusty Russell)
- Hotplug CPU removal (Rusty Russell)
- ext2/ext3 extended attribute & ACLs support (Ted Ts'o)
The rest (eg. hyperthread-aware scheduler, connection tracking optimizations)
don't really qualify as major new features as far as I can tell.
To ensure none of these get simply missed (rather than an actual decision
not to include them), it'd be nice to actually get "NAK"s once Linus gets
back. And at least if we have a finite "possible" list, we can judge how
frozen we really are.
It's a relatively short list: how many am I missing? (Dave?)
Rusty.
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
On Mon, 21 Oct 2002, Rusty Russell wrote:
|>On Sun, 20 Oct 2002 14:59:58 +0200 (CEST)
|>Roman Zippel <[email protected]> wrote:
|>> But now would be a good time to recapitulate things which Linus might have
|>> forgotten in the patching frenzy.
|>
|>Yes. If we only consider new arch-independent features which are actively
|>being pushed at the moment and are feature complete, I get the following
|>(much stolen from Guilluame: thanks!):
|>
|>- Build option for Linux Trace Toolkit (LTT) (Karim Yaghmour)
|>- Kernel Probes (Vamsi Krishna S)
|>- High resolution timers (George Anzinger, etc.)
|>- EVMS (Enterprise Volume Management System) (EVMS team)
|>- Device Mapper (lvm2) (Alasdair Kergon, Patrick Caulfield, Joe Thornber)
|>- New config system (Roman Zippel)
|>- In-kernel module loader (Rusty Russell)
|>- Unified boot/parameter support (Rusty Russell)
|>- Hotplug CPU removal (Rusty Russell)
|>- ext2/ext3 extended attribute & ACLs support (Ted Ts'o)
|>
|>The rest (eg. hyperthread-aware scheduler, connection tracking optimizations)
|>don't really qualify as major new features as far as I can tell.
I would think that LKCD fits in here. It's a feature, and important
to include as far as my team (and a number of distribution and OEMs)
believe.
|>To ensure none of these get simply missed (rather than an actual decision
|>not to include them), it'd be nice to actually get "NAK"s once Linus gets
|>back. And at least if we have a finite "possible" list, we can judge how
|>frozen we really are.
|>
|>It's a relatively short list: how many am I missing? (Dave?)
|>Rusty.
Please put LKCD in the list.
--Matt
From: Rusty Russell <[email protected]>
Date: Mon, 21 Oct 2002 13:51:37 +1000
It's a relatively short list: how many am I missing? (Dave?)
IPSEC from Alexey and myself, and new CryptoAPI from James Morris.
Rusty Russell wrote:
> On Sun, 20 Oct 2002 14:59:58 +0200 (CEST)
> Roman Zippel <[email protected]> wrote:
> > But now would be a good time to recapitulate things which Linus might have
> > forgotten in the patching frenzy.
>
> Yes. If we only consider new arch-independent features which are actively
> being pushed at the moment and are feature complete, I get the following
> (much stolen from Guilluame: thanks!):
>
> - Kernel Probes (Vamsi Krishna S)
You indicated in your last repost that Linus had commented on the code
which would imply he's planning to add it, but obviously he hasn't.
Maybe now would be a good time to share some of the accompanying code
that makes use of kprobes to get people interested. I've been playing
with it for a month now and have been patiently waiting for you to
share the rest of the code.
--
Skip
On Sunday 20 October 2002 22:51, Rusty Russell wrote:
> On Sun, 20 Oct 2002 14:59:58 +0200 (CEST)
>
> Roman Zippel <[email protected]> wrote:
> > But now would be a good time to recapitulate things which Linus might
> > have forgotten in the patching frenzy.
>
> Yes. If we only consider new arch-independent features which are actively
> being pushed at the moment and are feature complete, I get the following
> (much stolen from Guilluame: thanks!):
Sigh. If great minds think alike, how do you explain either of us then? :)
Collating time...
I'm trying to get URLs to patches with my list. (You'll notice Guilluame's
list has URLs, some of which are a bit out of date).
Here's a quick and dirty cut and paste of my list so far:
Roman Zippel's new kernel configuration system.
Announcement:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
Code:
http://www.xs4all.nl/~zippel/lc/
Ted Tso's new ext2/ext3 code with extended attributes and
access control lists.
Announcement:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
Code (chooe your poison):
bk://extfs.bkbits.net/extfs-2.5-update
http://thunk.org/tytso/linux/extfs-2.5
> > o Ready - Build option for Linux Trace Toolkit (LTT) (Karim Yaghmour)
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0832.html
>
> LTT has seen a number of changes since the posting above. Mainly,
> we've followed the recommendations of quite a few folks from the LKML.
> Here are some highlights summarizing the changes:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103491640202541&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103423004321305&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103247532007850&w=2
>
> The latest patch is available here:
> http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-
>021019-2.2.bz2 Use this patch with version 0.9.6pre2 of the user tools:
> http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz
>
> Karim
And other stuff from the original 2.5 status list's "ready" stuff (with URLs):
o in -ac PCMCIA Zoom video support (Alan Cox)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0326.html
o in -ac Device mapper for Logical Volume Manager (LVM2) (LVM2 team)
http://www.sistina.com/products_lvm.htm
o in -mm VM large page support (Many people)
http://lse.sourceforge.net/
o in -mm Page table sharing (Daniel Phillips, Dave McCracken)
http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
(A newer version of which seems to be at:)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
o Ready - Dynamic Probes (dprobes team)
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
o Ready - Zerocopy NFS (Hirokazu Takahashi)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
o Ready - High resolution timers (George Anzinger, etc.)
http://high-res-timers.sourceforge.net/
o Ready - EVMS (Enterprise Volume Management System) (EVMS team)
http://sourceforge.net/projects/evms
o Ready - Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
http://lkcd.sourceforge.net/
o Ready - Rewrite of the console layer (James Simmons)
http://linuxconsole.sourceforge.net/
To the above can be added the following recent submission on the list:
o Ready- Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
Now let's look what that leaves on your list:
> - Kernel Probes (Vamsi Krishna S)
Is this the same as dynamic probes?
> - In-kernel module loader (Rusty Russell)
> - Unified boot/parameter support (Rusty Russell)
> - Hotplug CPU removal (Rusty Russell)
I believe these are new. Do you have URLs?
> The rest (eg. hyperthread-aware scheduler, connection tracking
> optimizations) don't really qualify as major new features as far as I can
> tell.
>
> To ensure none of these get simply missed (rather than an actual decision
> not to include them), it'd be nice to actually get "NAK"s once Linus gets
> back. And at least if we have a finite "possible" list, we can judge how
> frozen we really are.
Replying to you, David S. Miller added:
> IPSEC from Alexey and myself, and new CryptoAPI from James Morris.
URLs to which would be nice.
And In a reply to me, Hans Reiser promised Reiser 4 by the 27th. (That's when
the cruise Linus is on ends, see my first "crunch time" post.) No URL yet,
since the code isn't done.
> It's a relatively short list: how many am I missing? (Dave?)
> Rusty.
That's all I know, collated into one amazingly ugly post. (Showing that even
with Red Hat 8's new pretty fonts, you can still cut and paste together an
incomprehensible, terribly formatted email. It's just more of a challenge.
:)
Rob
From: Rob Landley <[email protected]>
Date: Sun, 20 Oct 2002 21:44:59 -0500
> IPSEC from Alexey and myself, and new CryptoAPI from James Morris.
URLs to which would be nice.
No URLs, being coded as I type this :-)
Some of the ipv4 infrastructure is in 2.5.44
In article <[email protected]> (at Mon, 21 Oct 2002 00:43:28 -0700 (PDT)), "David S. Miller" <[email protected]> says:
> > IPSEC from Alexey and myself, and new CryptoAPI from James Morris.
>
> URLs to which would be nice.
>
> No URLs, being coded as I type this :-)
>
> Some of the ipv4 infrastructure is in 2.5.44
How about IPv6? We need it. :-)
--
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
In article <[email protected]> (at Sun, 20 Oct 2002 22:07:21 -0500), Rob Landley <[email protected]> says:
> On Monday 21 October 2002 02:59, YOSHIFUJI Hideaki wrote:
> > In article <[email protected]> (at Mon, 21 Oct 2002
> 00:43:28 -0700 (PDT)), "David S. Miller" <[email protected]> says:
> > > > IPSEC from Alexey and myself, and new CryptoAPI from James Morris.
> > >
> > > URLs to which would be nice.
> > >
> > > No URLs, being coded as I type this :-)
> > >
> > > Some of the ipv4 infrastructure is in 2.5.44
> >
> > How about IPv6? We need it. :-)
>
> At this point, we need a URL to a specific patch. (Ideas aren't going to be
> submitted to Linus by this time next week, code is. Preferably tested
> code...)
Well, our IPsec is ready, runs and is tested...
<ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/>
--
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
Rob Landley <[email protected]> writes:
> On Saturday 19 October 2002 07:41, Nicholas Wourms wrote:
>> Since I'm not a contributor, I know my opinion doesn't count for much.
>> Still, as a user I think it is important not to write of new features just
>> because they didn't make the "arbitrary" freeze date. Again, I really
>> don't see what the rush is all about.
>
> Who says anything about writing off features? 3.0 isn't the end of the world.
> The kernel team is trying to get it out now so people don't have to wait
> another year or more to use the new features that have ALREADY gotten in.
Quoting from
<http://groups.google.com/groups?selm=2hhl0l%2494r%40klaava.Helsinki.FI>:
"In short, the next version of linux (0.99.15) will be a "full-featured"
release, and only obvious bug-fixes to existing features will be applied
before calling it 1.0. If this means that your favourite feature or
networking version won't make it, don't despair: there is life even
after beta (and it's probably not worth mailing me about it any more:
I've seen quite a few favourite features already ;-)."
Regards, Olaf.
Updated my list with changes pointed out by Rob and Rusty.
http://www.kernelnewbies.org/status/
I am not too clear what exactly is expected to be merged for
IPv6 (everything from USAGI?) so I removed it and replaced
by IPsec and CryptoAPI.
Also, are initramfs, ext2/3 resize for 2.7/3.1?
-- Guillaume
On 20 Oct 2002 at 21:44, Rob Landley wrote:
> On Sunday 20 October 2002 22:51, Rusty Russell wrote:
> > On Sun, 20 Oct 2002 14:59:58 +0200 (CEST)
> >
> > Roman Zippel <[email protected]> wrote:
> > > But now would be a good time to recapitulate things which Linus might
> > > have forgotten in the patching frenzy.
> >
> > Yes. If we only consider new arch-independent features which are actively
> > being pushed at the moment and are feature complete, I get the following
> > (much stolen from Guilluame: thanks!):
>
> Sigh. If great minds think alike, how do you explain either of us then? :)
>
> Collating time...
>
> I'm trying to get URLs to patches with my list. (You'll notice Guilluame's
> list has URLs, some of which are a bit out of date).
>
> Here's a quick and dirty cut and paste of my list so far:
>
> Roman Zippel's new kernel configuration system.
> Announcement:
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
> Code:
> http://www.xs4all.nl/~zippel/lc/
>
>
> Ted Tso's new ext2/ext3 code with extended attributes and
> access control lists.
> Announcement:
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
> Code (chooe your poison):
> bk://extfs.bkbits.net/extfs-2.5-update
> http://thunk.org/tytso/linux/extfs-2.5
>
>
> > > o Ready - Build option for Linux Trace Toolkit (LTT) (Karim Yaghmour)
> > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0832.html
> >
> > LTT has seen a number of changes since the posting above. Mainly,
> > we've followed the recommendations of quite a few folks from the LKML.
> > Here are some highlights summarizing the changes:
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=103491640202541&w=2
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=103423004321305&w=2
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=103247532007850&w=2
> >
> > The latest patch is available here:
> > http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-
> >021019-2.2.bz2 Use this patch with version 0.9.6pre2 of the user tools:
> > http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz
> >
> > Karim
>
> And other stuff from the original 2.5 status list's "ready" stuff (with URLs):
>
> o in -ac PCMCIA Zoom video support (Alan Cox)
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0326.html
>
> o in -ac Device mapper for Logical Volume Manager (LVM2) (LVM2 team)
> http://www.sistina.com/products_lvm.htm
>
> o in -mm VM large page support (Many people)
> http://lse.sourceforge.net/
>
> o in -mm Page table sharing (Daniel Phillips, Dave McCracken)
> http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
> (A newer version of which seems to be at:)
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
>
> o Ready - Dynamic Probes (dprobes team)
> http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
>
> o Ready - Zerocopy NFS (Hirokazu Takahashi)
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
>
> o Ready - High resolution timers (George Anzinger, etc.)
> http://high-res-timers.sourceforge.net/
>
> o Ready - EVMS (Enterprise Volume Management System) (EVMS team)
> http://sourceforge.net/projects/evms
>
> o Ready - Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
> http://lkcd.sourceforge.net/
>
> o Ready - Rewrite of the console layer (James Simmons)
> http://linuxconsole.sourceforge.net/
>
> To the above can be added the following recent submission on the list:
>
> o Ready- Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
>
> Now let's look what that leaves on your list:
>
> > - Kernel Probes (Vamsi Krishna S)
>
> Is this the same as dynamic probes?
>
> > - In-kernel module loader (Rusty Russell)
> > - Unified boot/parameter support (Rusty Russell)
> > - Hotplug CPU removal (Rusty Russell)
>
> I believe these are new. Do you have URLs?
>
> > The rest (eg. hyperthread-aware scheduler, connection tracking
> > optimizations) don't really qualify as major new features as far as I can
> > tell.
> >
> > To ensure none of these get simply missed (rather than an actual decision
> > not to include them), it'd be nice to actually get "NAK"s once Linus gets
> > back. And at least if we have a finite "possible" list, we can judge how
> > frozen we really are.
>
> Replying to you, David S. Miller added:
>
> > IPSEC from Alexey and myself, and new CryptoAPI from James Morris.
>
> URLs to which would be nice.
>
> And In a reply to me, Hans Reiser promised Reiser 4 by the 27th. (That's when
> the cruise Linus is on ends, see my first "crunch time" post.) No URL yet,
> since the code isn't done.
>
> > It's a relatively short list: how many am I missing? (Dave?)
> > Rusty.
>
> That's all I know, collated into one amazingly ugly post. (Showing that even
> with Red Hat 8's new pretty fonts, you can still cut and paste together an
> incomprehensible, terribly formatted email. It's just more of a challenge.
> :)
>
> Rob
On Mon, 2002-10-21 at 05:04, David S. Miller wrote:
> From: Rusty Russell <[email protected]>
> Date: Mon, 21 Oct 2002 13:51:37 +1000
>
> It's a relatively short list: how many am I missing? (Dave?)
>
> IPSEC from Alexey and myself, and new CryptoAPI from James Morris.
Oh other one I missed - DVB layer - digital tv etc. Pretty much
essential now for europe, but again its basically all driver layer
On Mon, 2002-10-21 at 04:51, Rusty Russell wrote:
> - Device Mapper (lvm2) (Alasdair Kergon, Patrick Caulfield, Joe Thornber)
This is in my tree
> - New config system (Roman Zippel)
> - In-kernel module loader (Rusty Russell)
> - Unified boot/parameter support (Rusty Russell)
> - Hotplug CPU removal (Rusty Russell)
I guess much of this is now early 2.7.x stuff. Does mean more time to
get it really clean and to figure all the hotplug cpu issues before they
hit the official Linus tree
The big one missing is 32bit dev_t. Thats the killer item we have left.
The rest is mostly driver work, and some forward porting of major 2.4
features not yet in 2.5.
I'd love the split console stuff if it was ready but its not vital, and
I really want to get ucLinux merged or mostly merged
On Sun, Oct 20, 2002 at 05:49:41PM -0500, Rob Landley wrote:
> There will always be code that's not ready before the freeze, and that won't
> make it in. If this wasn't the case, there wouldn't be a need for a cutoff
> date, would there? "Oh, development is over, there are no more interesting
> new patches anywhere, we can all go home now." Doesn't happen.
Likewise, there _will_ be /some/ things that go in after the freeze.
- Things that are broken now that absolutely need fixing at all costs
before the freeze. Thankfully, most of this work seems to be driver
work. Some subsystems (ISDN, i2o, some of the net protos) need some
more indepth surgery, but this is imo all valid work that can happen
post freeze.
- Zero impact features.
As an example, now that the x86 subarch support is merged, even quite
large things, like support for Voyager has no impact on anything else
now. Likewise new filesystems as long as it doesn't require VFS
changes. (Something the Reiser4 folks seem to have realised).
- "Oops, this is totally broken" features.
There still seems no concensus on volume management for 2.6
Leaving existing LVM1 users dead in the water with the reply
"leave it to vendors to add the dm/evms patch" just doesn't seem
right. We need *something* for 2.6
AFAIAC, the freeze that happens on Linus return is really just a freeze
on core changes that have knock-on effects on other areas.
Lets worry about getting that right first, and hopefully we won't
have the 2.x.99 "this VM isn't quite right" holy wars yet again.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
Hi,
On 21 Oct 2002, Alan Cox wrote:
> > - New config system (Roman Zippel)
> > ...
>
> I guess much of this is now early 2.7.x stuff. Does mean more time to
> get it really clean and to figure all the hotplug cpu issues before they
> hit the official Linus tree
Above has no hotplug issues?!
It's ready, so why should we continue to suffer with cml1? I really heard
not a single argument against it yet.
bye, Roman
Dave Jones wrote:
> On Sun, Oct 20, 2002 at 05:49:41PM -0500, Rob Landley wrote:
>
> > There will always be code that's not ready before the freeze, and that
> > won't
> > make it in. If this wasn't the case, there wouldn't be a need for a
> > cutoff
> > date, would there? "Oh, development is over, there are no more
> > interesting
> > new patches anywhere, we can all go home now." Doesn't happen.
>
> Likewise, there _will_ be /some/ things that go in after the freeze.
>
> - Things that are broken now that absolutely need fixing at all costs
> before the freeze. Thankfully, most of this work seems to be driver
> work. Some subsystems (ISDN, i2o, some of the net protos) need some
> more indepth surgery, but this is imo all valid work that can happen
> post freeze.
> - Zero impact features.
> As an example, now that the x86 subarch support is merged, even quite
> large things, like support for Voyager has no impact on anything else
> now. Likewise new filesystems as long as it doesn't require VFS
> changes. (Something the Reiser4 folks seem to have realised).
> - "Oops, this is totally broken" features.
> There still seems no concensus on volume management for 2.6
> Leaving existing LVM1 users dead in the water with the reply
> "leave it to vendors to add the dm/evms patch" just doesn't seem
> right. We need *something* for 2.6
>
Thanks Dave, those were exactly the features I was worried about not getting
in 2.6.
Cheers,
Nicholas
On Monday 21 October 2002 06:22, Guillaume Boissiere wrote:
> Updated my list with changes pointed out by Rob and Rusty.
Cool. :)
> http://www.kernelnewbies.org/status/
But wait, there's more! :) Specfically, four or five new items at the end of
the list, a bit more research on the unresolved stuff, and one dropped item
(zoom support) which Alan said was just a driver forward-port from 2.4 rather
than a significant new feature.
I'll post the updated one in a minute or two...
> I am not too clear what exactly is expected to be merged for
> IPv6 (everything from USAGI?) so I removed it and replaced
> by IPsec and CryptoAPI.
I'm waiting to hear about that myself...
> Also, are initramfs, ext2/3 resize for 2.7/3.1?
Initramfs somebody has to ask Al Viro about, but at this point, the user space
stuff (including H. Peter Anvin's klib) to make initramfs useful isn't ready
enough for it to be useful, so I'm guessing it's next unstable series.
The main benefit from initramfs is the ability to rip stuff out of the kernel
and put it in userspace early. There's not likely to be much ripping out
done after the feature freeze, so even if the infrastructure went in at this
point...
Rob
Linus returns from the Linux Lunacy Cruise after Sunday, October 27th. The
following features aim to be ready for submission to Linus by Monday, October
28th, to be considered for inclusion (in 2.5.45) before the feature freeze on
Thursday, October 31 (halloween).
Note: if you want to submit a new entry to this list, PLEASE provide a URL
to where the patch can be found, and any descriptive announcement you think
useful (user space tools, etc). This doesn't have to be a web page devoted
to the patch, if the patch has been posted to linux-kernel a URL to the post
on any linux-kernel archive site should be fine.
If you don't know of one, a good site for looking at a threaded version of the
linux-kernel archive is http://lists.insecure.org/lists/linux-kernel/
and a keyword searchable archive is available at:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=mlist.linux.kernel
This list is just pending features trying to get in before feature freeze.
If you want to know what's already gone in, or what's being worked on for
the next development cycle, check out "http://kernelnewbies.org/status".
And now, in no particular order:
============================ Pending features: =============================
1) Roman Zippel's new kernel configuration system.
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
Code: http://www.xs4all.nl/~zippel/lc/
2) Ted Tso's new ext2/ext3 code with extended attributes and access control
lists.
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
Code: bk://extfs.bkbits.net/extfs-2.5-update
http://thunk.org/tytso/linux/extfs-2.5
Andreas Dilger says ext3 EA+ACL is now in the -mm tree.
3) Linux Trace Toolkit (LTT) (Karim Yaghmour)
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7016.html
Patch:
http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-021019-2.2.bz2
User tools: http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz
4) Device mapper for Logical Volume Manager (LVM2) (LVM2 team) (in -ac tree)
http://www.sistina.com/products_lvm.htm
5) VM large page support (Many people) (in -mm tree)
http://lse.sourceforge.net/
6) Page table sharing (Daniel Phillips, Dave McCracken) (in -mm tree)
http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
(A newer version of which seems to be at:)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
7) Dynamic Probes (dprobes team)
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
8) Zerocopy NFS (Hirokazu Takahashi)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
9) High resolution timers (George Anzinger, etc.)
http://high-res-timers.sourceforge.net/
10) EVMS (Enterprise Volume Management System) (EVMS team)
http://sourceforge.net/projects/evms
11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
Code: http://lkcd.sourceforge.net/
12) Rewrite of the console layer (James Simmons)
http://linuxconsole.sourceforge.net/
13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
14) USAGI IPv6.
Yoshifuji Hideyaki points out that ipv6 is very important overseas
(where some entire countries make do with a single class B ipv4
address range). He says:
> Well, our IPsec is ready, runs and is tested...
> ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/
15) MMU-less processor support (Greg Ungerer)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/7027.html
16) sys_epoll (Davide Libenzi)
homepage: http://www.xmailserver.org/linux-patches/nio-improve.html
patch: http://www.xmailserver.org/linux-patches/sys_epoll-2.5.44-0.3.diff
17) Kernel Hooks (IBM kernel team, contact: Richard J. Moore.)
http://www-124.ibm.com/linux/projects/kernelhooks/
18) CD Recording/sgio patches (Jens Axboe)
http://www.kernel.org/pub/linux/kernel/people/axboe/patches/v2.5/2.5.44/
19) In-kernel module loader (Rusty Russell.)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6214.html
20) Unlimited groups patch (Tim Hockin.)
Older (unified) version:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/1619.html
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/3885.html
Patch set:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/3884.html
http://lists.insecure.org/lists/linux-kernel/2002/Oct/3886.html
http://lists.insecure.org/lists/linux-kernel/2002/Oct/3888.html
http://lists.insecure.org/lists/linux-kernel/2002/Oct/3889.html
======================== Unresolved issues: =========================
1) Kernel Probes (Vamsi Krishna S)
Is this the same as dynamic probes?
2) Unified boot/parameter support (Rusty Russell)
3) Hotplug CPU removal (Rusty Russell)
Patches are available under:
http://www.kernel.org/pub/linux/kernel/people/rusty/patches
But there are a lot of them, and it's not quite clear what to
apply in what order. (I know Linus likes 'em broken up, but
an description and a pointer to a roll-up patch would be nice
for civilian testers. I moved the in-kernel module loader to
the main list because I found an announcement posting for it.)
4) hyperthread-aware scheduler
5) connection tracking optimizations.
No URLs to patch. Anybody want to come out in favor of these
with an announcement and pointer to a specific patch being
suggested for inclusion?
6) IPSEC (David Miller, Alexy)
7) New CryptoAPI (James Morris)
David S. Miller said:
> No URLs, being coded as I type this :-)
>
> Some of the ipv4 infrastructure is in 2.5.44
Note, this may conflict with Yoshifuji Hideyaki's ipv6 ipsec stuff. If not,
I'd like to collate or clarify the entries.) USAGI ipv6 is in the first
section and this isn't because I have a URL to an existing patch to
USAGI, and don't for this.
I actually have no idea how much overlap there is between these projects, and
whether they're considered parts of the same project or to be submitted
individually...
8) ReiserFS 4
Hans Reiser said:
> We will send Reiser4 out soon, probably around the 27th.
>
> Hans
See also http://www.namesys.com/v4/fast_reiser4.html
Hans and Jens Axboe are arguing about whether or not Reiser4 is a
potential post-freeze addition. That thread starts here:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/7140.html
9) Administrivia
I need to find a patch-friendly archive that works with "save-as" so
cut and paste doesn't get a chance to mess up whitespace on
patches people have posted to the list a while ago...
On Mon, 21 Oct 2002, Rob Landley wrote:
> 16) sys_epoll (Davide Libenzi)
> homepage: http://www.xmailserver.org/linux-patches/nio-improve.html
> patch: http://www.xmailserver.org/linux-patches/sys_epoll-2.5.44-0.3.diff
http://www.xmailserver.org/linux-patches/sys_epoll-2.5.44-0.5.diff
- Davide
Rob Landley wrote:
> 1) Roman Zippel's new kernel configuration system.
> Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
> Code: http://www.xs4all.nl/~zippel/lc/
I support merge, Linus seemed to support it with the caveat that he said
he didn't personally see much discussion...
> 2) Ted Tso's new ext2/ext3 code with extended attributes and access control
> lists.
> Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
> Code: bk://extfs.bkbits.net/extfs-2.5-update
> http://thunk.org/tytso/linux/extfs-2.5
No comment other than I notice tytso's patches got dropped (at least
once/twice?). Maybe viro hasn't reviewed them?
IIRC viro had some objections to ACLs in general and how they might not
necessarily actually improve security -- but I did not see detailed
elaboration on this.
> 3) Linux Trace Toolkit (LTT) (Karim Yaghmour)
> Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7016.html
> Patch:
> http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-021019-2.2.bz2
> User tools: http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz
I dunno if this needs to be in the kernel...
> 4) Device mapper for Logical Volume Manager (LVM2) (LVM2 team) (in -ac tree)
> http://www.sistina.com/products_lvm.htm
Needs sysfs support or devmapperfs support... no need to add a bunch of
ioctls that will go away eventually.
> 5) VM large page support (Many people) (in -mm tree)
> http://lse.sourceforge.net/
Rob - this URL doesn't seen to have anything directly to do with large
page support.
Others-
Is this not already in the kernel? I still want to actually see someone
from Oracle actually say "I will use this" or "we find this useful".
[I cynically propose a sys_oracle and be done with it <g>]
> 6) Page table sharing (Daniel Phillips, Dave McCracken) (in -mm tree)
> http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
> (A newer version of which seems to be at:)
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
IMO 2.7.x item...
> 7) Dynamic Probes (dprobes team)
> http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
why does this need to be the mainline kernel? this is another type of
thing that can live as a patch, IMO...
> 8) Zerocopy NFS (Hirokazu Takahashi)
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
this is already merged, isn't it??
> 9) High resolution timers (George Anzinger, etc.)
> http://high-res-timers.sourceforge.net/
no comment, I've heard arguments that high-res timers would be useful,
but haven't read the patch myself so won't comment...
> 10) EVMS (Enterprise Volume Management System) (EVMS team)
> http://sourceforge.net/projects/evms
Sounds like 2.7.x material, viro pointed out several problems ...
> 11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
> Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
> Code: http://lkcd.sourceforge.net/
I would personally _love_ to see this merged, but I think it's 2.7.x
material given the recent comments (unless they get fixed up)
> 12) Rewrite of the console layer (James Simmons)
> http://linuxconsole.sourceforge.net/
needs more review... but hasn't some of this stuff already made it in?
(or am I thinking about fbdev...?)
> 13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
Useful, but at the same time not many people will use this I think. It
may need to live as a patch for a while, if not for a long while...
> 14) USAGI IPv6.
>
> Yoshifuji Hideyaki points out that ipv6 is very important overseas
> (where some entire countries make do with a single class B ipv4
> address range). He says:
>
>
>>Well, our IPsec is ready, runs and is tested...
>>ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/
The USAGI guys have been slowly splitting up their patches and
submitting them... AFAIK DaveM is just waiting on more split-up IPv6
patches from them...
> 17) Kernel Hooks (IBM kernel team, contact: Richard J. Moore.)
> http://www-124.ibm.com/linux/projects/kernelhooks/
at first glance this seems to have serious issues with being a black
hole for overriding syscalls-type behavior...
> 19) In-kernel module loader (Rusty Russell.)
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6214.html
most likely 2.7.x material
> 20) Unlimited groups patch (Tim Hockin.)
I dunno if people want to take the hit in the mainline kernel... Maybe
this should be a CONFIG_xxx option, or live outside as a patch that
enterprise customers integrate
> 8) ReiserFS 4
>
> Hans Reiser said:
>
>
>>We will send Reiser4 out soon, probably around the 27th.
how mysterious... ;-)
>> 5) VM large page support (Many people) (in -mm tree)
>> http://lse.sourceforge.net/
>
> Rob - this URL doesn't seen to have anything directly to do with large page support.
>
> Others-
> Is this not already in the kernel? I still want to actually see someone from Oracle actually say "I will use this" or "we find this useful".
>
> [I cynically propose a sys_oracle and be done with it <g>]
Oracle are not the only users of this, nor the only database in
the world (though they often think they are) ;-)
There is *something* in the kernel ... whether it's useful or not
is a matter of opinion - what we see as remaining to do is to
provide hooks for generic interfaces (eg shmem, mmap, sbrk).
>> 6) Page table sharing (Daniel Phillips, Dave McCracken) (in -mm tree)
>> http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
>> (A newer version of which seems to be at:)
>> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
>
> IMO 2.7.x item...
Would be if it wasn't needed to alleviate all the overhead incurred
by rmap. As it is, the extra ZONE_NORMAL load kills large boxes dead ;-(
Will provide speedups for the fork+exec cycle for the low end too.
M.
On Monday 21 October 2002 21:02, Jeff Garzik wrote:
> Rob Landley wrote:
> > 1) Roman Zippel's new kernel configuration system.
> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
> > Code: http://www.xs4all.nl/~zippel/lc/
>
> I support merge, Linus seemed to support it with the caveat that he said
> he didn't personally see much discussion...
After CML2, I think everybody's too afraid to speak up. :)
> > 2) Ted Tso's new ext2/ext3 code with extended attributes and access
> > control lists.
> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
> > Code: bk://extfs.bkbits.net/extfs-2.5-update
> > http://thunk.org/tytso/linux/extfs-2.5
>
> No comment other than I notice tytso's patches got dropped (at least
> once/twice?). Maybe viro hasn't reviewed them?
Reading meaning into Linus dropping patches without explanation is like
reading meaning into sheep entrails. (At least with the entrails, you know
the future is likely to contain mutton.)
> > 5) VM large page support (Many people) (in -mm tree)
> > http://lse.sourceforge.net/
>
> Rob - this URL doesn't seen to have anything directly to do with large
> page support.
I got the URL straight from Guillaume's list. Haven't looked at it. I don't
use Oracle, and the largest box I have immediate access to has maybe 2
gigabytes of memory in it. (256 megs is pretty standard 'round here...)
> > 6) Page table sharing (Daniel Phillips, Dave McCracken) (in -mm tree)
> > http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
> > (A newer version of which seems to be at:)
> > http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
>
> IMO 2.7.x item...
Yes and no. Rmap went in already, and this mostly counteracts rmap's main
downside. Still, it is cutting it a bit close...
> > 7) Dynamic Probes (dprobes team)
> > http://oss.software.ibm.com/developerworks/opensource/linux/projects/dpro
> >bes
>
> why does this need to be the mainline kernel? this is another type of
> thing that can live as a patch, IMO...
Ask IBM. :)
> > 8) Zerocopy NFS (Hirokazu Takahashi)
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
>
> this is already merged, isn't it??
Another item straight from Guillaume's list...
> > 9) High resolution timers (George Anzinger, etc.)
> > http://high-res-timers.sourceforge.net/
>
> no comment, I've heard arguments that high-res timers would be useful,
> but haven't read the patch myself so won't comment...
I vaguely remember Linus had some objections that it plays with the clock tick
and potentially penalizes everybody... Hmmm...
A quick google comes up with this:
http://www.cs.helsinki.fi/linux/linux-kernel/2002-28/0360.html
> > 10) EVMS (Enterprise Volume Management System) (EVMS team)
> > http://sourceforge.net/projects/evms
>
> Sounds like 2.7.x material, viro pointed out several problems ...
This one's a problem. LVM1 is dead, so either LVM2 or EVMS are needed to
avoid a major functional regression vs 2.4...
> > 11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
> > Code: http://lkcd.sourceforge.net/
>
> I would personally _love_ to see this merged, but I think it's 2.7.x
> material given the recent comments (unless they get fixed up)
T minus 6 days, and counting... :)
> > 12) Rewrite of the console layer (James Simmons)
> > http://linuxconsole.sourceforge.net/
>
> needs more review... but hasn't some of this stuff already made it in?
> (or am I thinking about fbdev...?)
This and the page table sharing are probably the two that mean the most to me
personally, actually. Not that this is relevant... :)
> > 13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
> > http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
>
> Useful, but at the same time not many people will use this I think. It
> may need to live as a patch for a while, if not for a long while...
I have an odd usage that would be helped by having the linux kernel and a
ramdisk in the same image, but that's a question of getting support into lilo
or grub, not the linux kernel itself. There's probably already a way to do
it (actually, I'm sure I could if I wanted to hack lilo), it just hasn't made
it far enough up my to-do list yet...
> > 14) USAGI IPv6.
> >
> > Yoshifuji Hideyaki points out that ipv6 is very important overseas
> > (where some entire countries make do with a single class B ipv4
> >
> > address range). He says:
> >>Well, our IPsec is ready, runs and is tested...
> >>ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/
>
> The USAGI guys have been slowly splitting up their patches and
> submitting them... AFAIK DaveM is just waiting on more split-up IPv6
> patches from them...
Okay, ARE the Usagi IPV6 patches and Dave's work dovetailing into one project?
I'll happily collate them if so, I'd just like to hear it from one of the
principal authors...
Rob
Jeff Garzik wrote:
> > 3) Linux Trace Toolkit (LTT) (Karim Yaghmour)
> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7016.html
> > Patch:
> > http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-021019-2.2.bz2
> > User tools: http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz
>
> I dunno if this needs to be in the kernel...
We've had this debate with a couple of folks before, most notably with
Ingo Molnar. Here was the essence of my reply to Ingo then:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103272155416405&w=2
Ingo went on to provide us with a to-do list which we've complied with
100%.
Basically, there are plent of day-to-day user needs which LTT fills
perfectly. We don't expect users to recompile their kernel in order
to use a symbolic debugger and I don't see why users should need to
recompile their kernel to:
- solve complex inter-process interactions
- obtain exact measures regarding kernel vs. app time
- understand the exact dynamic interaction between their app, the
kernel and all the other processes running on the system.
- etc.
Here was Linus' take:
> I suspect we'll want to have some form of event tracing eventually, but
> I'm personally pretty convinced that it needs to be a per-CPU thing, and
> the core mechanism would need to be very lightweight.
From:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103271992115305&w=2
As I explained at that time to Linus, these are exactly the features we
are looking for in LTT. And since that posting, we've added precisely
those features (as I had promissed Linus, must I add), among many others
requested by folks on the LKML. If there's something we've missed, I'm
all ears.
Karim
===================================================
Karim Yaghmour
[email protected]
Embedded and Real-Time Linux Expert
===================================================
Rob Landley wrote:
> On Monday 21 October 2002 21:02, Jeff Garzik wrote:
>>>8) Zerocopy NFS (Hirokazu Takahashi)
>>>http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
>>
>>this is already merged, isn't it??
>
>
> Another item straight from Guillaume's list...
You can remove this item...
>>>10) EVMS (Enterprise Volume Management System) (EVMS team)
>>>http://sourceforge.net/projects/evms
>>
>>Sounds like 2.7.x material, viro pointed out several problems ...
>
>
> This one's a problem. LVM1 is dead, so either LVM2 or EVMS are needed to
> avoid a major functional regression vs 2.4...
A political regression only... if EVMS is not good enough for inclusion
in mainline, vendors can merge it and/or LVM2 to avoid problems. _We_
have higher standards for quality :) If no LVM is ready for 2.6.x, we
have no LVM. It's that simple... If no one has stepped up to clean up
LVM1, and LVM2 and EVMS are not ready for inclusion, there's not much we
can do about it. That's _not_ a reason to merge crap...
>>>14) USAGI IPv6.
>>>
>>>Yoshifuji Hideyaki points out that ipv6 is very important overseas
>>>(where some entire countries make do with a single class B ipv4
>>>
>>>address range). He says:
>>>
>>>>Well, our IPsec is ready, runs and is tested...
>>>>ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/
>>>
>>The USAGI guys have been slowly splitting up their patches and
>>submitting them... AFAIK DaveM is just waiting on more split-up IPv6
>>patches from them...
>
>
> Okay, ARE the Usagi IPV6 patches and Dave's work dovetailing into one project?
> I'll happily collate them if so, I'd just like to hear it from one of the
> principal authors...
I'm sure he can elaborate, but AFAIK DaveM and Alexey are only doing
IPSEC... where USAGI and IPSEC intersect, there will be clashes. So if
USAGI is waiting on IPSEC to submit more patches, things are waiting on
DaveM. But if there are IPSEC-independent patches, USAGI should go
ahead and send them :)
Jeff
Em Mon, Oct 21, 2002 at 10:53:03PM -0400, Jeff Garzik escreveu:
> >Okay, ARE the Usagi IPV6 patches and Dave's work dovetailing into one
> >project? I'll happily collate them if so, I'd just like to hear it from
> >one of the principal authors...
> I'm sure he can elaborate, but AFAIK DaveM and Alexey are only doing
> IPSEC... where USAGI and IPSEC intersect, there will be clashes. So if
> USAGI is waiting on IPSEC to submit more patches, things are waiting on
> DaveM. But if there are IPSEC-independent patches, USAGI should go
> ahead and send them :)
They are sending it, and David already stated here that he will be using some
pieces of USAGI's ipsec work, but the core is being coded by him and Alexey.
- Arnaldo
On Mon, 2002-10-21 at 17:42, Rob Landley wrote:
> On Monday 21 October 2002 21:02, Jeff Garzik wrote:
> > Rob Landley wrote:
>
> > > 9) High resolution timers (George Anzinger, etc.)
> > > http://high-res-timers.sourceforge.net/
> >
> > no comment, I've heard arguments that high-res timers would be useful,
> > but haven't read the patch myself so won't comment...
>
> I vaguely remember Linus had some objections that it plays with the clock tick
> and potentially penalizes everybody... Hmmm...
>
> A quick google comes up with this:
>
> http://www.cs.helsinki.fi/linux/linux-kernel/2002-28/0360.html
George said he would change the code to meet Linus's issues (re the sub
jiffies stuff). But there was not much debate either way, and I suspect
George may in fact be correct.
George also offered an interface-only version of the patch that
implements the POSIX clocks and timers syscalls, without the high
resolution support, so it would be nice to at the very least merge the
missing POSIX functionality.
Robert Love
In message <[email protected]> you write:
> On Mon, 2002-10-21 at 04:51, Rusty Russell wrote:
> > - Device Mapper (lvm2) (Alasdair Kergon, Patrick Caulfield, Joe Thornb
er)
>
> This is in my tree
>
> > - New config system (Roman Zippel)
> > - In-kernel module loader (Rusty Russell)
> > - Unified boot/parameter support (Rusty Russell)
> > - Hotplug CPU removal (Rusty Russell)
>
> I guess much of this is now early 2.7.x stuff.
The new config system and in-kernel module loader are the kind of
wrenching changes which are never nice, now or in 2.7. Both are about
as well tested as they're going to get (no external tree will merge
either, since the first means constant patch rejects and the second
means new userspace tools requirements).
In particular, the module code solves real races while making current
ones no worse. It does printk() module refcount bugs in drivers: it
depends how long the shakeout process is going to be.
The unified boot & parameter support depends on the in-kernel module
loader (part of that "additional flexibility" I keep talking about for
the in-kernel loader). Old-style parameters are still supported, so
it's low impact to drivers.
The Hotplug CPU removal is a noop on architectures which don't want
it: Linus took "add" some time back, but remove has been pending since
then. I'm testing x86 "remove" now, which makes it more accessible
and useful to other people.
> The big one missing is 32bit dev_t. Thats the killer item we have left.
> The rest is mostly driver work, and some forward porting of major 2.4
> features not yet in 2.5.
Is there a patch for this in existence?
> I'd love the split console stuff if it was ready but its not vital, and
> I really want to get ucLinux merged or mostly merged
OK, here is my current list.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Key:
A: Author
M: lkml posting describing patch
W: Download
N: Random notes
In rough order of invasiveness (mostly guesses):
In-kernel Module Loader
A: Rusty Russell
W: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/
N: Requires new modutils
Kernel Config
A: Roman Zippel
M: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
W: http://www.xs4all.nl/~zippel/lc/
Linux Trace Toolkit (LTT)
A: Karim Yaghmour
M: http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0832.html
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103491640202541&w=2
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103423004321305&w=2
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103247532007850&w=2
W: http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-021019-2.2.bz2
ucLinux Patch (MMU-less support)
A: Greg Ungerer
M: http://lwn.net/Articles/11016/
W: http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.38uc2.patch.gz
Fbdev Rewrite
A: James Simmons
W: http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
initramfs
A: Al Viro
M: http://www.cs.helsinki.fi/linux/linux-kernel/2001-30/0110.html
W: ftp://ftp.math.psu.edu/pub/viro/N0-initramfs-C21
ext2/ext3 ACLs and Extended Attributes
A: Ted Ts'o
M: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
B: bk://extfs.bkbits.net/extfs-2.5-update
W: http://thunk.org/tytso/linux/extfs-2.5
High Resolution Timers
A: George Anzinger
W: http://high-res-timers.sourceforge.net/
Hotplug CPU Removal
A: Rusty Russell
W: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Hotplug/
Device Mapper (LVM2)
A: LWM2 Team
W: http://www.sistina.com/products_lvm.htm
N: In -ac kernels
Kernel Probes
A: Vamsi Krishna S
M: lists.insecure.org/linux-kernel/2002/Aug/1299.html
W: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Misc/kprobes.patch.gz
EVMS
A: EVMS Team
W: http://sourceforge.net/projects/evms
Crash Dumping (LKCD)
A: Matt Robinson, LKCD team
W: http://lkcd.sourceforge.net/
IPSec
A: David Miller and Alexey Kuznetsov
Crypto API
A: James Morris
Unified Boot/Module Parameter Support
A: Rusty Russell
W: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/
N: Depends on in-kernel module loader
In message <[email protected]> you write:
> Sigh. If great minds think alike, how do you explain either of us then? =
> :)
"Fools never differ" perhaps?
I'm not worried about stuff which is in -mm: they won't get lost, and
some of them will get thrown out if the benchmarks don't pay off.
> o in -ac PCMCIA Zoom video support (Alan Cox)=20
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0326.html
Hmm... is this merely a new driver or significant new infrastructure?
> o Ready - Dynamic Probes (dprobes team)=20
> http://oss.software.ibm.com/developerworks/opensource/linux/projects/dpro=
> bes
The minimal kernel part of this is kprobes.
> o Ready - Zerocopy NFS (Hirokazu Takahashi)=20
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
This is really up to Dave. I thought he was already merging it?
> And In a reply to me, Hans Reiser promised Reiser 4 by the 27th. (That's=
Another filesystem can go in during the freeze, unless it makes
infrastructure changes?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
On Mon, 2002-10-21 at 20:00, Rob Landley wrote:
> Anybody know if he made this change?
I don't think so. Its an implementation detail that can be worked out
after the freeze, anyhow.
> Any comments on which of these three patches Linus should
> personally have the opportunity to turn down after the 27th?
>
> http://sourceforge.net/projects/high-res-timers
I do not think Linus should have the opportunity to turn down any of
these patches.
Only one of them has been sent to him, the high-res-timers, and I think
he should merge it.
Robert Love
From: Rusty Russell <[email protected]>
Date: Tue, 22 Oct 2002 12:26:26 +1000
> o Ready - Zerocopy NFS (Hirokazu Takahashi)=20
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
This is really up to Dave. I thought he was already merging it?
The net/ipv{4,6} infrastructure is in, the nfs maintainers just
need to put in the sunrpc/nfs* bits. :-)
Rob Landley wrote:
>
> On Monday 21 October 2002 22:20, Robert Love wrote:
> > On Mon, 2002-10-21 at 17:42, Rob Landley wrote:
>
> > George said he would change the code to meet Linus's issues (re the sub
> > jiffies stuff). But there was not much debate either way, and I suspect
> > George may in fact be correct.
>
> Anybody know if he made this change?
Uh, what I will offer is:
1.) Posix clock & timers NOT HIGH RES
2.) A three patch set to put in high-res-timers:
a.) The core kernel timer.c stuff
b.) The i386 high res stuff
c.) A patch to increase the POSIX clocks & timers to high
res.
>
> > George also offered an interface-only version of the patch that
> > implements the POSIX clocks and timers syscalls, without the high
> > resolution support, so it would be nice to at the very least merge the
> > missing POSIX functionality.
> >
> > Robert Love
>
> Any comments on which of these three patches Linus should personally have the
> opportunity to turn down after the 27th?
>
> http://sourceforge.net/projects/high-res-timers
None of them :) I will post a new set against the latest
kernel. Working....
-g
--
George Anzinger [email protected]
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
Rob Landley wrote:
>
> On Monday 21 October 2002 21:02, Jeff Garzik wrote:
> > Rob Landley wrote:
> > > 1) Roman Zippel's new kernel configuration system.
> > > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
> > > Code: http://www.xs4all.nl/~zippel/lc/
> >
> > I support merge, Linus seemed to support it with the caveat that he said
> > he didn't personally see much discussion...
>
> After CML2, I think everybody's too afraid to speak up. :)
>
> > > 2) Ted Tso's new ext2/ext3 code with extended attributes and access
> > > control lists.
> > > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
> > > Code: bk://extfs.bkbits.net/extfs-2.5-update
> > > http://thunk.org/tytso/linux/extfs-2.5
> >
> > No comment other than I notice tytso's patches got dropped (at least
> > once/twice?). Maybe viro hasn't reviewed them?
>
> Reading meaning into Linus dropping patches without explanation is like
> reading meaning into sheep entrails. (At least with the entrails, you know
> the future is likely to contain mutton.)
>
> > > 5) VM large page support (Many people) (in -mm tree)
> > > http://lse.sourceforge.net/
> >
> > Rob - this URL doesn't seen to have anything directly to do with large
> > page support.
>
> I got the URL straight from Guillaume's list. Haven't looked at it. I don't
> use Oracle, and the largest box I have immediate access to has maybe 2
> gigabytes of memory in it. (256 megs is pretty standard 'round here...)
>
> > > 6) Page table sharing (Daniel Phillips, Dave McCracken) (in -mm tree)
> > > http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
> > > (A newer version of which seems to be at:)
> > > http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
> >
> > IMO 2.7.x item...
>
> Yes and no. Rmap went in already, and this mostly counteracts rmap's main
> downside. Still, it is cutting it a bit close...
>
> > > 7) Dynamic Probes (dprobes team)
> > > http://oss.software.ibm.com/developerworks/opensource/linux/projects/dpro
> > >bes
> >
> > why does this need to be the mainline kernel? this is another type of
> > thing that can live as a patch, IMO...
>
> Ask IBM. :)
>
> > > 8) Zerocopy NFS (Hirokazu Takahashi)
> > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
> >
> > this is already merged, isn't it??
>
> Another item straight from Guillaume's list...
>
> > > 9) High resolution timers (George Anzinger, etc.)
> > > http://high-res-timers.sourceforge.net/
> >
> > no comment, I've heard arguments that high-res timers would be useful,
> > but haven't read the patch myself so won't comment...
>
> I vaguely remember Linus had some objections that it plays with the clock tick
> and potentially penalizes everybody... Hmmm...
>
> A quick google comes up with this:
>
> http://www.cs.helsinki.fi/linux/linux-kernel/2002-28/0360.html
Hm, I had not seen this. He is right, but the patch
provides an out :) The standard says a timer can overrun.
If a timer is repeating so fast as to bogdown the system,
the code lumps enough of them to unload the system into the
overrun count and doesn't take the interrupts.
-g
>
> > > 10) EVMS (Enterprise Volume Management System) (EVMS team)
> > > http://sourceforge.net/projects/evms
> >
> > Sounds like 2.7.x material, viro pointed out several problems ...
>
> This one's a problem. LVM1 is dead, so either LVM2 or EVMS are needed to
> avoid a major functional regression vs 2.4...
>
> > > 11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
> > > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
> > > Code: http://lkcd.sourceforge.net/
> >
> > I would personally _love_ to see this merged, but I think it's 2.7.x
> > material given the recent comments (unless they get fixed up)
>
> T minus 6 days, and counting... :)
>
> > > 12) Rewrite of the console layer (James Simmons)
> > > http://linuxconsole.sourceforge.net/
> >
> > needs more review... but hasn't some of this stuff already made it in?
> > (or am I thinking about fbdev...?)
>
> This and the page table sharing are probably the two that mean the most to me
> personally, actually. Not that this is relevant... :)
>
> > > 13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
> > > http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
> >
> > Useful, but at the same time not many people will use this I think. It
> > may need to live as a patch for a while, if not for a long while...
>
> I have an odd usage that would be helped by having the linux kernel and a
> ramdisk in the same image, but that's a question of getting support into lilo
> or grub, not the linux kernel itself. There's probably already a way to do
> it (actually, I'm sure I could if I wanted to hack lilo), it just hasn't made
> it far enough up my to-do list yet...
>
> > > 14) USAGI IPv6.
> > >
> > > Yoshifuji Hideyaki points out that ipv6 is very important overseas
> > > (where some entire countries make do with a single class B ipv4
> > >
> > > address range). He says:
> > >>Well, our IPsec is ready, runs and is tested...
> > >>ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/
> >
> > The USAGI guys have been slowly splitting up their patches and
> > submitting them... AFAIK DaveM is just waiting on more split-up IPv6
> > patches from them...
>
> Okay, ARE the Usagi IPV6 patches and Dave's work dovetailing into one project?
> I'll happily collate them if so, I'd just like to hear it from one of the
> principal authors...
>
> Rob
> -
> 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/
--
George Anzinger [email protected]
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
Jeff Garzik <[email protected]> writes:
> > 13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
> > http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
>
> Useful, but at the same time not many people will use this I think. It may need
> to live as a patch for a while, if not for a long while...
Hmm. 2+ years is not enough?
A couple of comments.
The limitation to the ELF file format is long gone, (so the summary is
incorrect). sys_kexec can launch any random kernel, it just needs an
appropriate user space program that understands the format. kexec
bzImage works, and I suspect kexec could even start booting windows
from the boot sector of a hard drive.
The code has been looked at, and discussed by the kmonte, and bootimg
authors, and the kexec interface has not been found to be a problem.
Except for tracking kernel interface changes the code really has not
needed to change in quite a long while.
The biggest challenge right now is to track down the strange and
mysterious failures caused by driver or BIOS bugs. Kexec is
inherently open to a bug anywhere in the system causing it to fail.
The development work consists of writing code, and inventing
techniques to track down those mysterious failures. Kernel debuggers
don't work when you don't have a running kernel.
All of this is generic kernel stabilization work, and it sounds to me
like a good complement to the upcoming 2.5.x stabilization efforts.
A smallish user base may be a good argument against it. But I unless
I have miscounted there are quite a few people playing with bootimg,
and kmonte, not to mention the earlier versions of kexec.
To do things right sys_kexec needs access to call device_shutdown, and
the reboot notifier chain. The latter is available only as a static
variable in kernel/sys.c. And neither of them are exported from the
kernel.
Keeping sys_kexec out of the kernel seems to encourage half baked,
half debugged implementations that just work for their authors, and
are limited to what it is easy to do as a module.
Putting in the sys_kexec patch in the kernel will certainly discourage
hacks in the code, and encourage those last few strange mysterious
failures to be tracked. Plus it will put pressure on driver
maintainers to fix various bugs in their code. And the patch is
not very intrusive at all so I fail to see a downside except bloat.
Eric
On Monday 21 October 2002 22:42, Rusty Russell wrote:
> OK, here is my current list.
> Rusty.
And for reference, here's my current list (not yet collated with yours). In
theory, both of these will feed into Guillaume's current list. What's going
to feed into Linus's current list is anybody's guess...
Rob
Robert Love wrote:
> I do not think Linus should have the opportunity to turn down any of
> these patches.
>
> Only one of them has been sent to him, the high-res-timers, and I think
> he should merge it.
um, huh? Linus's job is to turn down patches...
On Mon, 21 Oct 2002, Rob Landley wrote:
|>On Monday 21 October 2002 21:02, Jeff Garzik wrote:
|>> Rob Landley wrote:
|>> > 11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
|>> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
|>> > Code: http://lkcd.sourceforge.net/
|>>
|>> I would personally _love_ to see this merged, but I think it's 2.7.x
|>> material given the recent comments (unless they get fixed up)
|>
|>T minus 6 days, and counting... :)
We've incorporated the majority of Christoph's requests, along
with changes requested by a few other developers. We'll post the
next set later tonight after testing a few SMP/UP/IDE/SCSI crashes
with all of the changes.
There are a couple of things that we didn't change due to the
nature of the project, which I'll first discuss with Christoph
off-line to avoid going down a big rathole. :) Suffice it to
say that we incorporated almost everything he asked for.
We'll make this deadline.
--Matt
On Mon, Oct 21, 2002 at 10:02:33PM -0400, Jeff Garzik wrote:
> > 11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
> > Code: http://lkcd.sourceforge.net/
>
> I would personally _love_ to see this merged, but I think it's 2.7.x
> material given the recent comments (unless they get fixed up)
The few core changes they make are fine - the rest is purely driver work.
IMHO we should merge the core dump infrastructure (i.e. notifiers,
Kerntypes, etc..) - the rest can be added when ready and before that you
should be able to simply load an externally compiled dump.o anyway..
Jeff Garzik wrote:
>>>>10) EVMS (Enterprise Volume Management System) (EVMS team)
>>>>http://sourceforge.net/projects/evms
>>>
>>>Sounds like 2.7.x material, viro pointed out several problems ...
>>
>>
>> This one's a problem. LVM1 is dead, so either LVM2 or EVMS are needed to
>> avoid a major functional regression vs 2.4...
>
> A political regression only... if EVMS is not good enough for inclusion
> in mainline, vendors can merge it and/or LVM2 to avoid problems. _We_
> have higher standards for quality :) If no LVM is ready for 2.6.x, we
> have no LVM. It's that simple... If no one has stepped up to clean up
> LVM1, and LVM2 and EVMS are not ready for inclusion, there's not much we
> can do about it. That's _not_ a reason to merge crap...
>
As was stated by Dave Jones[1], this is something that will probably should
go in after the freeze. I'm afraid that having seperate patches is just
unacceptable. There are many of us out there who use LVM, and I don't
think it is appropriate to release a kernel without it. Obviously you
haven't been paying attention because Joe Thornber has been actively honing
the device mapper interface over the last couple of weeks. AFAICT, he has
addressed all of the issues which were discussed in the critique of his
code. Alan's had it in his tree for awhile now, which shows that it is at
least partially suitable. When it's ready to go in, I'm sure it'll meet
your standards. As for EVMS, I'd consider that a whole different beast.
Can you mount LVM partitions with using EVMS tools? We should probably
keep the two seperate if this is not the case.
Cheers,
Nicholas
[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=103520598902877&w=2
On Tue, Oct 22, 2002 at 01:32:49PM -0400, Nicholas Wourms wrote:
> As was stated by Dave Jones[1], this is something that will probably should
> go in after the freeze. I'm afraid that having seperate patches is just
> unacceptable.
If you want your volume manager of choice beein included in 2.6 help to
get it in shape quickly. It's rather simple..
Christoph Hellwig wrote:
> On Tue, Oct 22, 2002 at 01:32:49PM -0400, Nicholas Wourms wrote:
>
>>As was stated by Dave Jones[1], this is something that will probably should
>>go in after the freeze. I'm afraid that having seperate patches is just
>>unacceptable.
>
>
> If you want your volume manager of choice beein included in 2.6 help to
> get it in shape quickly. It's rather simple..
>
Like arguing with a brick wall...
>>> Nicholas Wourms <[email protected]> 10/22/02 01:32PM >>>
<snip>
> Can you mount LVM partitions with using EVMS tools? We should probably
> keep the two seperate if this is not the case.
Yes indeed you can. And much, much more.
Cheers,
Also Nicholas
> Cheers,
> Nicholas
On Tue, 2002-10-22 at 18:48, Nicholas Wourms wrote:
> Christoph Hellwig wrote:
> > On Tue, Oct 22, 2002 at 01:32:49PM -0400, Nicholas Wourms wrote:
> >
> >>As was stated by Dave Jones[1], this is something that will probably should
> >>go in after the freeze. I'm afraid that having seperate patches is just
> >>unacceptable.
> >
> >
> > If you want your volume manager of choice beein included in 2.6 help to
> > get it in shape quickly. It's rather simple..
> >
>
> Like arguing with a brick wall...
I will agree. I will observe two details
1. The wall normally wins
2. Christoph is right
In the mean time it would really help if people took the EVMS/LVM2
debate down to the technical aspects not the marketing ones (at least on
this list). That means fixing the bugs, cleaning up the code, auditing
it etc.
The folks who want to have long rambling discussions rather than fix the
code or test it are encouraged to find a private brick wall, bartender
(or different list) to talk at
On Monday 21 October 2002 06:22, Guillaume Boissiere wrote:
> Also, are initramfs, ext2/3 resize for 2.7/3.1?
The online resize stuff has been suffering because I've been terribly
busy at work. Even so, it can be merged after the 2.5 code freeze,
since it is internal to ext3 and does not affect any APIs.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
On Tue, Oct 22, 2002 at 01:47:39PM -0600, Andreas Dilger wrote:
> On Monday 21 October 2002 06:22, Guillaume Boissiere wrote:
> > Also, are initramfs, ext2/3 resize for 2.7/3.1?
>
> The online resize stuff has been suffering because I've been terribly
> busy at work. Even so, it can be merged after the 2.5 code freeze,
> since it is internal to ext3 and does not affect any APIs.
Nevertheless, it means any ext3 stability testing done post-freeze
would be invalidated by addition of a new _feature_.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
mbs wrote:
>
> On Tuesday 22 October 2002 02:45, george anzinger wrote:
> > > > > 9) High resolution timers (George Anzinger, etc.)
> > > > > http://high-res-timers.sourceforge.net/
> > > >
> > > > no comment, I've heard arguments that high-res timers would be useful,
> > > > but haven't read the patch myself so won't comment...
> > >
> > > I vaguely remember Linus had some objections that it plays with the clock
> > > tick and potentially penalizes everybody... Hmmm...
> > >
> > > A quick google comes up with this:
> > >
> > > http://www.cs.helsinki.fi/linux/linux-kernel/2002-28/0360.html
> >
> > Hm, I had not seen this. He is right, but the patch
> > provides an out :) The standard says a timer can overrun.
> > If a timer is repeating so fast as to bogdown the system,
> > the code lumps enough of them to unload the system into the
> > overrun count and doesn't take the interrupts.
> > -g
>
> (I haven't done my homework and looked in your patch)
>
> you did notice the bit in posix about repeating timers and how you dont
> reinsert a repeating timer until the signal handler has completed, right?
What the standard says is that only one signal is to be
queued for a given timer. Subsequent expires of the same
timer then just bump the overrun count. This is what the
patch does, but still this could overload the timer list and
interrupt code, so in addition to the standard required
overrun stuff, the code checks the next expire time and
fudges a time at least X microseconds from now, where the
time is a multiple (Y) of the repeat time + the current
expire time. Y is then added to the overrun count to
account for the missing expires.
>
> that one bit me and we actually had to reimplement portions of our signals
> mechanism to accomodate it.
Yes, the signal code needs to check for that pending timer.
And NOW (i.e. 2.5) it can be in either the shared list or
the local list or both :(. This is in the patch.
>
> that behavior ensures that a POSIX timer can't entirely dominate the system
> (although it certainly can put a hurt on as can any number of other ill
> advised programming blunders)
I would be open to requiring a capability to run the repeat
time below a fixed value if this would make folks happier.
It would send the right message to the user, too, i.e. small
repeat counts can be hazardous to your system.
>
> it however doesn't do anything for kernel things using the timer
> infrastructure....
The interesting thing is that we don't currently have an in
kernel call such as delay, etc. You just use add_timer().
AND none of the possible interfaces I have seen or
considered even hint at needing repeating timers.
--
George Anzinger [email protected]
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
On Oct 22, 2002 20:57 +0100, Dave Jones wrote:
> On Tue, Oct 22, 2002 at 01:47:39PM -0600, Andreas Dilger wrote:
> > On Monday 21 October 2002 06:22, Guillaume Boissiere wrote:
> > > Also, are initramfs, ext2/3 resize for 2.7/3.1?
> >
> > The online resize stuff has been suffering because I've been terribly
> > busy at work. Even so, it can be merged after the 2.5 code freeze,
> > since it is internal to ext3 and does not affect any APIs.
>
> Nevertheless, it means any ext3 stability testing done post-freeze
> would be invalidated by addition of a new _feature_.
No, because if you looked at the code for the online resize (even if it
is enabled, which is separately selectable), you would see it is
equivalent to the following in ext3_ioctl() and ext3_setup_super():
if (doing online resize)
do something;
else
don't even see any difference;
The resize code does not impact any code paths in the normal operation
of the filesystem, and 99% could even be put into a separate module,
that's how detached it is from the main ext3 code.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
On Tue, 2002-10-22 at 20:57, Dave Jones wrote:
> Nevertheless, it means any ext3 stability testing done post-freeze
> would be invalidated by addition of a new _feature_.
No serious ext3 testing done so far is worth anything anyway. Im pretty
sure ext3 resize will beat driver code that passes cerberus reliably..
On Tue, Oct 22, 2002 at 02:18:43PM -0600, Andreas Dilger wrote:
> if (doing online resize)
> do something;
> else
> don't even see any difference;
>
> The resize code does not impact any code paths in the normal operation
> of the filesystem, and 99% could even be put into a separate module,
> that's how detached it is from the main ext3 code.
Fairy nuff. Sounds promising.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On Tue, Oct 22, 2002 at 02:06:29AM +0000, Jeff Garzik wrote:
>
> > 7) Dynamic Probes (dprobes team)
> > http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
>
> why does this need to be the mainline kernel? this is another type of
> thing that can live as a patch, IMO...
>
We are not proposing the entire dprobes patch to be in kernel. It doesn't
have to be. We are proposing for inclusion the "kprobes" patchset at
http://www-124.ibm.com/linux/patches/?project_id=141 which provides
the basic infrastructure in the kernel for setting up and handling
breakpoints automatically in kernel space. Once this small piece is in,
we can implement comprehensive tools like dynamic probes as external
kernel modules without having to patch the kernel.
--
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: [email protected]
On Tuesday 22 October 2002 12:32, Nicholas Wourms wrote:
> As was stated by Dave Jones[1], this is something that will probably should
> go in after the freeze.
This is just a thought, and it's from somebody who's not going to actually be
making any of these decisions, but my idea of "goes in after the freeze" is
the same as my idea of "goes in during the stable series".
If you'd be happy including something between stable.0 and stable.1, or
stable.5 and stable.6, (whether "stable" is called "2.6", "3.0", or "fred")
then it makes sense to put it in after the freeze. But if you don't think it
would be a good idea to insert it after stable.0, then inserting it after the
freeze at all is a bit hypocritical. (Otherwise the freeze isn't too
meaningful.)
Now, given that, if it could go in during the stable series, why not wait
until then and not confuse the issue during stabilization and shutdown of the
-pre series? (Or at least hold off until closer to dot-0 release date, and
give the existing infrastructure a chance to settle down a bit first. At the
very least not rush to get too much in immediately after the freeze.)
Admittedly the first dozen releases of 2.4 are a bad example of "stable", but
reiserfs did go in circa 2.4.1 and nobody really minded that bit. Maybe LVM
and EVMS are similar, self contained, can't possibly hurt anybody who isn't
using it type things. (I don't know. The word "maybe" is an important
weasel word in that sentence.)
Rob
--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
On Wednesday 23 October 2002 05:28, Vamsi Krishna S . wrote:
> We are not proposing the entire dprobes patch to be in kernel. It doesn't
> have to be. We are proposing for inclusion the "kprobes" patchset at
> http://www-124.ibm.com/linux/patches/?project_id=141 which provides
> the basic infrastructure in the kernel for setting up and handling
> breakpoints automatically in kernel space. Once this small piece is in,
> we can implement comprehensive tools like dynamic probes as external
> kernel modules without having to patch the kernel.
Okay, so if patch 1 is kprobes itself, what exactly is the status of patches
2-4? (Optional but nice? Cleanups? Or are you pushing as hard for them as
for part 1?)
I thought 2-4 paved the way for dprobes, but if you're not trying to get
dprobes in...?
Rob
--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
On Wed, Oct 23, 2002 at 11:03:20AM -0500, Rob Landley wrote:
> On Wednesday 23 October 2002 05:28, Vamsi Krishna S . wrote:
>
> > We are not proposing the entire dprobes patch to be in kernel. It doesn't
> > have to be. We are proposing for inclusion the "kprobes" patchset at
> > http://www-124.ibm.com/linux/patches/?project_id=141 which provides
> > the basic infrastructure in the kernel for setting up and handling
> > breakpoints automatically in kernel space. Once this small piece is in,
> > we can implement comprehensive tools like dynamic probes as external
> > kernel modules without having to patch the kernel.
>
> Okay, so if patch 1 is kprobes itself, what exactly is the status of patches
> 2-4? (Optional but nice? Cleanups? Or are you pushing as hard for them as
> for part 1?)
>
2-4 are additional features which are required to implement a tool like
dprobes. It is nice to have them all in the kernel, so full-featured tools
like dprobes could be built without touching the kernel.
> I thought 2-4 paved the way for dprobes, but if you're not trying to get
> dprobes in...?
>
dprobes doesn't have to be in the mainline kernel, but dprobes (or
any such tool) requires some basic support from the kernel for setting
up breakpoints. kprobes provides these fundamental facilities which
are useable as-is.
Thanks,
Vamsi.
--
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: [email protected]