The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
drivers/gpu/drm/i810/{i810,i830}_dma.c:
Fixable, but needs someone with the hardware to test. Can probably be
marked CONFIG_BROKEN_ON_SMP if nobody cares.
drivers/media/video (V4L):
Mauro is working on it, some drivers get moved to staging while the
others get fixed. An easy workaround would be possible by adding
per-driver mutexes, but Mauro wants to it properly by locking all
the right places.
fs/adfs:
Probably not hard to fix, but needs someone to test it.
adfs has only seen janitorial fixes for the last 5 years.
Do we know of any users?
fs/autofs:
Pretty much dead, replaced by autofs4. I'd suggest moving this
to drivers/staging in 2.6.37 and letting it die there.
fs/coda:
Coda seems to have an active community, but not all of their
code is actually part of linux (pioctl!), while the last official
release is missing many of the cleanups that were don in Linux.
Not sure what to do, if someone is interested, the best way might
be a fresh start with a merger of the mainline linux and the
coda.cs.cmu.edu codebase in drivers/staging.
Just removing the BKL without the Coda community seems like a heap
of pointless work.
fs/freevxfs:
Uses the BKL in readdir and lookup, should be easy to fix. Christoph?
fs/hpfs:
Looks fixable, if anyone cares. Maybe it's time for retirement in
drivers/staging though. The web page only has a Link to the
linux-2.2 version.
fs/lockd:
Trond writes that he has someone working on BKL removal here.
fs/locks.c:
Patch is under discussion, blocked by work on fs/lockd currently.
fs/ncpfs:
Should be fixable if Petr still cares about it. Otherwise suggest
moving to drivers/staging if there are no users left.
fs/qnx4:
Should be easy to fix, there are only a few places in the code that
use the BKL. Anders?
fs/smbfs:
Last I heard this was considered obsolete. Should be move it to
drivers/staging now?
fs/udf:
Not completely trivial, but probably necessary to fix. Project web
site is dead, I hope that Jan Kara can be motivated to fix it though.
fs/ufs:
Evgeniy Dushistov is maintaining this, I hope he can take care of
getting rid of the BKL in UFS.
kernel/trace/blktrace.c:
Should be easy. Ingo? Steven?
net/appletalk:
net/ipx/af_ipx.c:
net/irda/af_irda.c:
Can probably be saved from retirement in drivers/staging if the
maintainers still care.
net/x25:
Andrew Hendry has started working on it.
This is all that's left now. I still need to submit a few patches for
simple file system changes, but it seems we're getting closer to finally
killing it for good.
Arnd
From: Steven Rostedt <rostedt@goodmis.org> Date: 2010-09-16 14:49:09
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
kernel/trace/blktrace.c:
Should be easy. Ingo? Steven?
Jens,
Git blame shows this to be your code (copied from block/blktrace.c from
years past).
Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
-- Steve
net/appletalk:
net/ipx/af_ipx.c:
net/irda/af_irda.c:
Can probably be saved from retirement in drivers/staging if the
maintainers still care.
IPX and Appletalk both have active users. They also look fairly fixable
as the lock_kernel just maps to a stack private mutex, or in several
cases can simply be dropped - its just a push down legacy.
IRDA may well be a candidate for staging
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
quoted
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
quoted
kernel/trace/blktrace.c:
Should be easy. Ingo? Steven?
Jens,
Git blame shows this to be your code (copied from block/blktrace.c from
years past).
Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
It isn't, it can be removed.
--
Jens Axboe
Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.
net/appletalk:
net/ipx/af_ipx.c:
net/irda/af_irda.c:
Can probably be saved from retirement in drivers/staging if the
maintainers still care.
IPX and Appletalk both have active users. They also look fairly fixable
as the lock_kernel just maps to a stack private mutex, or in several
cases can simply be dropped - its just a push down legacy.
From: Anton Altaparmakov <hidden> Date: 2010-09-16 21:26:24
Hi,
On 16 Sep 2010, at 16:04, Jan Kara wrote:
On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
quoted
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
...
quoted
fs/ncpfs:
Should be fixable if Petr still cares about it. Otherwise suggest
moving to drivers/staging if there are no users left.
I think some people still use this...
Yes, indeed. Netware is still alive (unfortunately!) and ncpfs is used in a lot of Universities here in the UK at least (we use it about a thousand workstations and servers here at Cambridge University!).
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
On Thursday 16 September 2010, Anton Altaparmakov wrote:
On 16 Sep 2010, at 16:04, Jan Kara wrote:
quoted
On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
quoted
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
...
quoted
fs/ncpfs:
Should be fixable if Petr still cares about it. Otherwise suggest
moving to drivers/staging if there are no users left.
I think some people still use this...
Yes, indeed. Netware is still alive (unfortunately!) and ncpfs is used in a lot of
Universities here in the UK at least (we use it about a thousand workstations and
servers here at Cambridge University!).
Ok, that means at least when someone gets around to fix it, there will be
people that can test the patches.
If you know someone who would like to help on this, it would be nice to try
out the patch below, unless someone can come up with a better solution.
My naïve understanding of the code tells me that simply using the super block
lock there may work. In fact it makes locking stricter, so if it still works
with that patch, there are probably no subtle regressions.
The patch applies to current linux-next of my bkl/vfs series.
Arnd
---
ncpfs: replace BKL with lock_super
This mindlessly changes every instance of lock_kernel in ncpfs to
lock_super. I haven't tested this, it may work or may break horribly.
Please test with CONFIG_LOCKDEP enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
@@ -844,8 +843,9 @@ static int ncp_ioctl_need_write(unsigned int cmd)longncp_ioctl(structfile*filp,unsignedintcmd,unsignedlongarg){longret;+structsuper_block*sb=filp->f_path.dentry->d_inode->i_sb;-lock_kernel();+lock_super(sb);if(ncp_ioctl_need_write(cmd)){/**insidetheioctl(),anyfailureswhich
@@ -863,19 +863,20 @@ long ncp_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)mnt_drop_write(filp->f_path.mnt);out:-unlock_kernel();+unlock_super(sb);returnret;}#ifdef CONFIG_COMPATlongncp_compat_ioctl(structfile*file,unsignedintcmd,unsignedlongarg){+structsuper_block*sb=file->f_path.dentry->d_inode->i_sb;longret;-lock_kernel();+lock_super(sb);arg=(unsignedlong)compat_ptr(arg);ret=ncp_ioctl(file,cmd,arg);-unlock_kernel();+unlock_super(sb);returnret;}#endif
From: Christoph Hellwig <hch@infradead.org> Date: 2010-09-17 13:32:31
On Fri, Sep 17, 2010 at 12:45:41PM +0200, Arnd Bergmann wrote:
ncpfs: replace BKL with lock_super
Err, no. lock_super is just as much on it's way out as the BKL. We've
managed to move it down from the VFS into a few remaining filesystems
and now need to get rid of those users. Please don't add any new ones.
On Friday 17 September 2010, Christoph Hellwig wrote:
On Fri, Sep 17, 2010 at 12:45:41PM +0200, Arnd Bergmann wrote:
quoted
ncpfs: replace BKL with lock_super
Err, no. lock_super is just as much on it's way out as the BKL. We've
managed to move it down from the VFS into a few remaining filesystems
and now need to get rid of those users. Please don't add any new ones.
Ok. I guess that's also a NAK for my the isofs patch I posted yesterday
then. Do you have any suggestions for an alternative approach?
Arnd
From: Christoph Hellwig <hch@infradead.org> Date: 2010-09-17 14:02:27
On Fri, Sep 17, 2010 at 03:50:49PM +0200, Arnd Bergmann wrote:
On Friday 17 September 2010, Christoph Hellwig wrote:
quoted
On Fri, Sep 17, 2010 at 12:45:41PM +0200, Arnd Bergmann wrote:
quoted
ncpfs: replace BKL with lock_super
Err, no. lock_super is just as much on it's way out as the BKL. We've
managed to move it down from the VFS into a few remaining filesystems
and now need to get rid of those users. Please don't add any new ones.
Ok. I guess that's also a NAK for my the isofs patch I posted yesterday
then. Do you have any suggestions for an alternative approach?
Just add a per-sb mutex inside the filesystem. Given that lock_super
isn't used by the VFS anymore that's actually equivalent.
On Thursday 16 September 2010 20:32:36 Jens Axboe wrote:
On 2010-09-16 16:49, Steven Rostedt wrote:
quoted
Git blame shows this to be your code (copied from block/blktrace.c from
years past).
Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
It isn't, it can be removed.
Ok, I queued up this patch now. Thanks!
Arnd
---
Subject: [PATCH] blktrace: remove the big kernel lock
According to Jens, this code does not need the BKL at all,
it is sufficiently serialized by bd_mutex.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jens Axboe <redacted>
Cc: Steven Rostedt <rostedt@goodmis.org>
This is a update on the current progress for the BKL removal, reflecting
what is currently in linux-next.
Maybe we can briefly discuss this at the kernel summit to decide if we
want a quick death of the BKL, i.e. fixing/disabling/staging-out the
remaining users in 2.6.38 or rather leave them there indefinitely.
On Thursday 16 September 2010, Arnd Bergmann wrote:
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
drivers/gpu/drm/i810/{i810,i830}_dma.c:
Fixable, but needs someone with the hardware to test. Can probably be
marked CONFIG_BROKEN_ON_SMP if nobody cares.
Still open, no good solution for this.
drivers/media/video (V4L):
Mauro is working on it, some drivers get moved to staging while the
others get fixed. An easy workaround would be possible by adding
per-driver mutexes, but Mauro wants to it properly by locking all
the right places.
Progressing well, patches are being worked on.
fs/adfs:
Probably not hard to fix, but needs someone to test it.
adfs has only seen janitorial fixes for the last 5 years.
Do we know of any users?
Nobody replied.
fs/autofs:
Pretty much dead, replaced by autofs4. I'd suggest moving this
to drivers/staging in 2.6.37 and letting it die there.
Now in staging.
fs/coda:
Coda seems to have an active community, but not all of their
code is actually part of linux (pioctl!), while the last official
release is missing many of the cleanups that were don in Linux.
Not sure what to do, if someone is interested, the best way might
be a fresh start with a merger of the mainline linux and the
coda.cs.cmu.edu codebase in drivers/staging.
Just removing the BKL without the Coda community seems like a heap
of pointless work.
Jan Harkes showed interest, looks like this will get fixed eventually,
but probably not in time for 2.6.37.
fs/freevxfs:
Uses the BKL in readdir and lookup, should be easy to fix. Christoph?
Still waiting for confirmation from Christoph Hellwig that the BKL
is not needed here. I can do the patch to remove it then.
fs/hpfs:
Looks fixable, if anyone cares. Maybe it's time for retirement in
drivers/staging though. The web page only has a Link to the
linux-2.2 version.
No replies.
fs/lockd:
Trond writes that he has someone working on BKL removal here.
Bryan Schumaker took care of this, looks like the locking is independent
of the fs/locks.c locking now, although it still uses the BKL internally.
I assume that this will get fixed as well, doesn't seem hard. As long
as lockd uses the BKL, both nfs and nfsd depend on the BKL implicitly.
fs/locks.c:
Patch is under discussion, blocked by work on fs/lockd currently.
No longer blocked now, both lockd and ceph can deal with this converted
to spinlocks. I will follow up with the final patch once they hit mainline.
fs/ncpfs:
Should be fixable if Petr still cares about it. Otherwise suggest
moving to drivers/staging if there are no users left.
Fixed by Petr Vandrovec.
fs/qnx4:
Should be easy to fix, there are only a few places in the code that
use the BKL. Anders?
Anders Larsen volunteered.
fs/smbfs:
Last I heard this was considered obsolete. Should be move it to
drivers/staging now?
Now in staging.
fs/udf:
Not completely trivial, but probably necessary to fix. Project web
site is dead, I hope that Jan Kara can be motivated to fix it though.
Jan Kara volunteered to do it.
fs/ufs:
Evgeniy Dushistov is maintaining this, I hope he can take care of
getting rid of the BKL in UFS.
No replies.
kernel/trace/blktrace.c:
Should be easy. Ingo? Steven?
Done.
net/appletalk:
net/ipx/af_ipx.c:
net/irda/af_irda.c:
Can probably be saved from retirement in drivers/staging if the
maintainers still care.
Samuel Ortiz fixed irda.
David Miller volunteered to do appletalk and ipx.
net/x25:
Andrew Hendry has started working on it.
Patches have shown up in -next now, I suppose Andrew will finish it soon.
Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
up not getting fixed at all, we can either mark them non-SMP or move them
to drivers/staging once all the others are done.
Arnd
From: Christoph Hellwig <hch@infradead.org> Date: 2010-10-18 16:19:24
Before we get into all these fringe drivers:
- I've not seen any progrss on ->get_sb BKL removal for a while
- locks.c is probably a higher priorit, too.
On Monday 18 October 2010 18:19:24 Christoph Hellwig wrote:
Before we get into all these fringe drivers:
- I've not seen any progrss on ->get_sb BKL removal for a while
Not sure what you mean. Jan Blunck did the pushdown into get_sb
last year, which is included into linux-next through my bkl/vfs
tree. Subsequent patches remove it from most file systems along with
the other BKL uses in them. If you like, I can post the series
once more, but it has been posted a few times now.
- locks.c is probably a higher priorit, too.
As mentioned in the list, I expect the trivial final patch to
be applied in 2.6.37-rc1 after Linus has pulled the trees that
this depends on (bkl/vfs, nfs, nfsd, ceph), see below.
This is currently not in -next because of the prerequisites.
Arnd
---
On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
up not getting fixed at all, we can either mark them non-SMP or move them
to drivers/staging once all the others are done.
I recommend moving them to staging, and then retire them from there if
no one steps up to maintain them.
thanks,
greg k-h
From: Dave Airlie <airlied@gmail.com> Date: 2010-10-18 23:00:12
On Tue, Oct 19, 2010 at 4:43 AM, Greg KH [off-list ref] wrote:
On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
quoted
Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
up not getting fixed at all, we can either mark them non-SMP or move them
to drivers/staging once all the others are done.
I recommend moving them to staging, and then retire them from there if
no one steps up to maintain them.
I think this sets a bad precedent, these drivers work fine. Removing
BKL from them is hard, and involves finding and booting hw that
developers don't have much time/interest in at the moment. Anyone who
has access to the i810 hw and has time to work out the locking has
more important things to be doing with modern hw, however it doesn't
mean we should just drop support for old drivers because they don't
have active maintainers. Removing the BKL from the kernel is a great
goal, but breaking userspace ABI by removing drivers isn't.
Dave.
On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
On Tue, Oct 19, 2010 at 4:43 AM, Greg KH [off-list ref] wrote:
quoted
On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
quoted
Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
up not getting fixed at all, we can either mark them non-SMP or move them
to drivers/staging once all the others are done.
I recommend moving them to staging, and then retire them from there if
no one steps up to maintain them.
I think this sets a bad precedent, these drivers work fine. Removing
BKL from them is hard, and involves finding and booting hw that
developers don't have much time/interest in at the moment. Anyone who
has access to the i810 hw and has time to work out the locking has
more important things to be doing with modern hw, however it doesn't
mean we should just drop support for old drivers because they don't
have active maintainers. Removing the BKL from the kernel is a great
goal, but breaking userspace ABI by removing drivers isn't.
Should we just restrict such drivers to only be able to build on UP
machines with preempt disabled so that the BKL could be safely removed
from them?
Or what other idea do you have as to what could be done here?
I do have access to this hardware, but its on an old single processor
laptop, so any work that it would take to help do this development,
really wouldn't be able to be tested to be valid at all.
thanks,
greg k-h
From: Dave Airlie <airlied@gmail.com> Date: 2010-10-19 00:57:43
On Tue, Oct 19, 2010 at 10:40 AM, Greg KH [off-list ref] wrote:
On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
quoted
On Tue, Oct 19, 2010 at 4:43 AM, Greg KH [off-list ref] wrote:
quoted
On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
quoted
Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
up not getting fixed at all, we can either mark them non-SMP or move them
to drivers/staging once all the others are done.
I recommend moving them to staging, and then retire them from there if
no one steps up to maintain them.
I think this sets a bad precedent, these drivers work fine. Removing
BKL from them is hard, and involves finding and booting hw that
developers don't have much time/interest in at the moment. Anyone who
has access to the i810 hw and has time to work out the locking has
more important things to be doing with modern hw, however it doesn't
mean we should just drop support for old drivers because they don't
have active maintainers. Removing the BKL from the kernel is a great
goal, but breaking userspace ABI by removing drivers isn't.
Should we just restrict such drivers to only be able to build on UP
machines with preempt disabled so that the BKL could be safely removed
from them?
Or what other idea do you have as to what could be done here?
I do have access to this hardware, but its on an old single processor
laptop, so any work that it would take to help do this development,
really wouldn't be able to be tested to be valid at all.
There is only very rare case where the i830 driver might get used with
SMP and really I think that case is in the don't care place, since if
you have that hw you probably should be using i915 on it anyways.
So it really only leaves the problem case of what do distros do if we
mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
when you boot the SMP kernels on UP they don't run as SMP so not
having the driver load on those is a problem. Maybe we just need some
sort of warn on smp if a smp unfriendly driver is loaded and we
transition to SMP mode. Though this sounds like either (a) something
we do now and I don't about it, (b) work.
Dave.
On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote:
On Tue, Oct 19, 2010 at 10:40 AM, Greg KH [off-list ref] wrote:
quoted
On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
quoted
On Tue, Oct 19, 2010 at 4:43 AM, Greg KH [off-list ref] wrote:
quoted
On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
quoted
Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
up not getting fixed at all, we can either mark them non-SMP or move them
to drivers/staging once all the others are done.
I recommend moving them to staging, and then retire them from there if
no one steps up to maintain them.
I think this sets a bad precedent, these drivers work fine. Removing
BKL from them is hard, and involves finding and booting hw that
developers don't have much time/interest in at the moment. Anyone who
has access to the i810 hw and has time to work out the locking has
more important things to be doing with modern hw, however it doesn't
mean we should just drop support for old drivers because they don't
have active maintainers. Removing the BKL from the kernel is a great
goal, but breaking userspace ABI by removing drivers isn't.
Should we just restrict such drivers to only be able to build on UP
machines with preempt disabled so that the BKL could be safely removed
from them?
Or what other idea do you have as to what could be done here?
I do have access to this hardware, but its on an old single processor
laptop, so any work that it would take to help do this development,
really wouldn't be able to be tested to be valid at all.
There is only very rare case where the i830 driver might get used with
SMP and really I think that case is in the don't care place, since if
you have that hw you probably should be using i915 on it anyways.
So, there is no need for the i830 driver? Can it just be removed
because i915 works instead?
So it really only leaves the problem case of what do distros do if we
mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
when you boot the SMP kernels on UP they don't run as SMP so not
having the driver load on those is a problem. Maybe we just need some
sort of warn on smp if a smp unfriendly driver is loaded and we
transition to SMP mode. Though this sounds like either (a) something
we do now and I don't about it, (b) work.
So you are saying that just because distros will never build such a
thing, we should keep it building for SMP mode? Why not prevent it from
being built and if a distro really cares, then they will pony up the
development to fix the driver up?
In other words, if someone really cares, then they will do the work,
otherwise why worry? Especially as it seems that no one here is going
to do it, right?
thanks,
greg k-h
From: Dave Airlie <airlied@gmail.com> Date: 2010-10-19 02:45:43
On Tue, Oct 19, 2010 at 12:24 PM, Greg KH [off-list ref] wrote:
On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote:
quoted
On Tue, Oct 19, 2010 at 10:40 AM, Greg KH [off-list ref] wrote:
quoted
On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
quoted
On Tue, Oct 19, 2010 at 4:43 AM, Greg KH [off-list ref] wrote:
quoted
On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
quoted
Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
up not getting fixed at all, we can either mark them non-SMP or move them
to drivers/staging once all the others are done.
I recommend moving them to staging, and then retire them from there if
no one steps up to maintain them.
I think this sets a bad precedent, these drivers work fine. Removing
BKL from them is hard, and involves finding and booting hw that
developers don't have much time/interest in at the moment. Anyone who
has access to the i810 hw and has time to work out the locking has
more important things to be doing with modern hw, however it doesn't
mean we should just drop support for old drivers because they don't
have active maintainers. Removing the BKL from the kernel is a great
goal, but breaking userspace ABI by removing drivers isn't.
Should we just restrict such drivers to only be able to build on UP
machines with preempt disabled so that the BKL could be safely removed
from them?
Or what other idea do you have as to what could be done here?
I do have access to this hardware, but its on an old single processor
laptop, so any work that it would take to help do this development,
really wouldn't be able to be tested to be valid at all.
There is only very rare case where the i830 driver might get used with
SMP and really I think that case is in the don't care place, since if
you have that hw you probably should be using i915 on it anyways.
So, there is no need for the i830 driver? Can it just be removed
because i915 works instead?
No because it provides a different userspace ABI to the i915 driver to
a different userspace X driver etc.
like I'm sure the intersection of this driver and reality are getting
quite limited, but its still a userspace ABI change and needs to be
treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
old driver/API.
quoted
So it really only leaves the problem case of what do distros do if we
mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
when you boot the SMP kernels on UP they don't run as SMP so not
having the driver load on those is a problem. Maybe we just need some
sort of warn on smp if a smp unfriendly driver is loaded and we
transition to SMP mode. Though this sounds like either (a) something
we do now and I don't about it, (b) work.
So you are saying that just because distros will never build such a
thing, we should keep it building for SMP mode? Why not prevent it from
being built and if a distro really cares, then they will pony up the
development to fix the driver up?
Distros build the driver now even it it didn't work on SMP it wouldn't
matter to the 99% of people who have this hw since it can't suppport
SMP except in some corner cases. So not building for SMP is the same
as just throwing it out of the kernel since most people don't run
kernel.org kernels, and shouldn't have to just to get a driver for
some piece of hardware that worked fine up until now.
Look at this from a user who has this hardware pov, it works for them
now with a distro kernel, us breaking it isn't going to help that user
or make any distro care, its just going to screw over the people who
are actually using it.
In other words, if someone really cares, then they will do the work,
otherwise why worry? Especially as it seems that no one here is going
to do it, right?
Well the thing is doing the work right is a non-trivial task and just
dropping support only screws the people using the hardware,
it doesn't place any burden on the distro developers to fix it up. If
people are really serious about making the BKL go away completely, I
think the onus should be on them to fix the drivers not on the users
who are using it, like I'm guessing if this gets broken the bug will
end up in Novell or RH bugzilla in a year and nobody will ever see it.
Dave.
From: Steven Rostedt <rostedt@goodmis.org> Date: 2010-10-19 03:33:39
On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote:
On Tue, Oct 19, 2010 at 12:24 PM, Greg KH [off-list ref] wrote:
quoted
So, there is no need for the i830 driver? Can it just be removed
because i915 works instead?
No because it provides a different userspace ABI to the i915 driver to
a different userspace X driver etc.
like I'm sure the intersection of this driver and reality are getting
quite limited, but its still a userspace ABI change and needs to be
treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
old driver/API.
Thus, you are saying that this will break for people with older user
apps and have a newer kernel?
quoted
quoted
So it really only leaves the problem case of what do distros do if we
mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
when you boot the SMP kernels on UP they don't run as SMP so not
having the driver load on those is a problem. Maybe we just need some
sort of warn on smp if a smp unfriendly driver is loaded and we
transition to SMP mode. Though this sounds like either (a) something
we do now and I don't about it, (b) work.
So you are saying that just because distros will never build such a
thing, we should keep it building for SMP mode? Why not prevent it from
being built and if a distro really cares, then they will pony up the
development to fix the driver up?
Distros build the driver now even it it didn't work on SMP it wouldn't
matter to the 99% of people who have this hw since it can't suppport
SMP except in some corner cases. So not building for SMP is the same
as just throwing it out of the kernel since most people don't run
kernel.org kernels, and shouldn't have to just to get a driver for
some piece of hardware that worked fine up until now.
Ah! Exactly! Thus, those that do not run kernel.org kernels are using a
distro kernel. Wont these same people use the distro userspace? That is,
if they have upgraded their kernel, most likely, they also update their
X interface.
Look at this from a user who has this hardware pov, it works for them
now with a distro kernel, us breaking it isn't going to help that user
or make any distro care, its just going to screw over the people who
are actually using it.
But they can use the i915 driver instead, because they are using the
newer userspace apps.
quoted
In other words, if someone really cares, then they will do the work,
otherwise why worry? Especially as it seems that no one here is going
to do it, right?
Well the thing is doing the work right is a non-trivial task and just
dropping support only screws the people using the hardware,
it doesn't place any burden on the distro developers to fix it up. If
people are really serious about making the BKL go away completely, I
think the onus should be on them to fix the drivers not on the users
who are using it, like I'm guessing if this gets broken the bug will
end up in Novell or RH bugzilla in a year and nobody will ever see it.
Well the problem comes down to testing it. I don't know of any developer
that is removing the BKL that actually owns hardware to test out these
broken drivers. And for the change not being trivial, means that there's
no way to do in correctly.
-- Steve
From: Dave Airlie <airlied@gmail.com> Date: 2010-10-19 04:03:20
quoted
like I'm sure the intersection of this driver and reality are getting
quite limited, but its still a userspace ABI change and needs to be
treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
old driver/API.
Thus, you are saying that this will break for people with older user
apps and have a newer kernel?
There are two drivers here:
i810
i830
The i830 case is the case I care less about since the ABI is only used
by older userspace and i915 provides a replacement.
the i810 case ABI is still in use today by distro userspaces that are
still released, i.e. i810 is still used in F14, Ubuntu 10.10, RHEL6
Beta etc.
I've snipped the rest of the argument on the grounds you are
conflating two cases that aren't the same.
quoted
Well the thing is doing the work right is a non-trivial task and just
dropping support only screws the people using the hardware,
it doesn't place any burden on the distro developers to fix it up. If
people are really serious about making the BKL go away completely, I
think the onus should be on them to fix the drivers not on the users
who are using it, like I'm guessing if this gets broken the bug will
end up in Novell or RH bugzilla in a year and nobody will ever see it.
Well the problem comes down to testing it. I don't know of any developer
that is removing the BKL that actually owns hardware to test out these
broken drivers. And for the change not being trivial, means that there's
no way to do in correctly.
So we can drop i830 using deprecation, however its pointless since the
fix for i810 is the same fix for i830 if we can work out the fix.
Well the way to do it correctly is make it so if the driver is
initialised and we do an SMP transition we warn the users, or we make
BROKEN_ON_SMP into a runtime thing that warns when the driver is
loaded on an SMP system. The intersection of SMP and this hardware is
definitely a very very small number and a lot more workable.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Dave Airlie <airlied@gmail.com> Date: 2010-10-19 04:52:32
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
Dave.
On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote:
quoted
On Tue, Oct 19, 2010 at 12:24 PM, Greg KH [off-list ref] wrote:
quoted
quoted
So, there is no need for the i830 driver? Can it just be removed
because i915 works instead?
No because it provides a different userspace ABI to the i915 driver to
a different userspace X driver etc.
like I'm sure the intersection of this driver and reality are getting
quite limited, but its still a userspace ABI change and needs to be
treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
old driver/API.
Thus, you are saying that this will break for people with older user
apps and have a newer kernel?
quoted
quoted
quoted
So it really only leaves the problem case of what do distros do if we
mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
when you boot the SMP kernels on UP they don't run as SMP so not
having the driver load on those is a problem. Maybe we just need some
sort of warn on smp if a smp unfriendly driver is loaded and we
transition to SMP mode. Though this sounds like either (a) something
we do now and I don't about it, (b) work.
So you are saying that just because distros will never build such a
thing, we should keep it building for SMP mode? Why not prevent it from
being built and if a distro really cares, then they will pony up the
development to fix the driver up?
Distros build the driver now even it it didn't work on SMP it wouldn't
matter to the 99% of people who have this hw since it can't suppport
SMP except in some corner cases. So not building for SMP is the same
as just throwing it out of the kernel since most people don't run
kernel.org kernels, and shouldn't have to just to get a driver for
some piece of hardware that worked fine up until now.
Ah! Exactly! Thus, those that do not run kernel.org kernels are using a
distro kernel. Wont these same people use the distro userspace? That is,
if they have upgraded their kernel, most likely, they also update their
X interface.
quoted
Look at this from a user who has this hardware pov, it works for them
now with a distro kernel, us breaking it isn't going to help that user
or make any distro care, its just going to screw over the people who
are actually using it.
But they can use the i915 driver instead, because they are using the
newer userspace apps.
quoted
quoted
In other words, if someone really cares, then they will do the work,
otherwise why worry? Especially as it seems that no one here is going
to do it, right?
Well the thing is doing the work right is a non-trivial task and just
dropping support only screws the people using the hardware,
it doesn't place any burden on the distro developers to fix it up. If
people are really serious about making the BKL go away completely, I
think the onus should be on them to fix the drivers not on the users
who are using it, like I'm guessing if this gets broken the bug will
end up in Novell or RH bugzilla in a year and nobody will ever see it.
Well the problem comes down to testing it. I don't know of any developer
that is removing the BKL that actually owns hardware to test out these
broken drivers. And for the change not being trivial, means that there's
no way to do in correctly.
-- Steve
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Theodore Kilgore
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
quoted
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() > 1) {
pr_err("i810 no longer supports SMP\n");
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Arnd
From: Steven Rostedt <rostedt@goodmis.org> Date: 2010-10-19 12:39:58
On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
quoted
quoted
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() > 1) {
pr_err("i810 no longer supports SMP\n");
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
I think we also need to cover the PREEMPT case too. But that could be a
compile time check, since you can't boot a preempt kernel and make it
non preempt.
-- Steve
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
quoted
quoted
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() > 1) {
pr_err("i810 no longer supports SMP\n");
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Some research showed that Intel never support i810/i815 SMP setups,
but there was indeed one company (http://www.acorpusa.com at the time,
now owned by a domain squatter) that made i815E based dual Pentium-III
boards like this one: http://cgi.ebay.com/280319795096
The first person that can send me an authentic log file showing the
use of X.org with DRM on a 2.6.35 kernel with two processors on that
mainboard dated today or earlier gets a free upgrade to an AGP graphics
card of comparable or better 3D performance from me. Please include
the story how why you are running this machine with a new kernel.
i830 is harder, apparently some i865G boards support Pentium 4 with HT
and even later dual-core processors.
Arnd
From: Paul Mundt <hidden> Date: 2010-10-19 13:54:46
On Tue, Oct 19, 2010 at 08:39:58AM -0400, Steven Rostedt wrote:
On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
quoted
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
quoted
quoted
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() > 1) {
pr_err("i810 no longer supports SMP\n");
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
I think we also need to cover the PREEMPT case too. But that could be a
compile time check, since you can't boot a preempt kernel and make it
non preempt.
There are enough nameless embedded vendors that have turned a preempt
kernel in to a non-preempt one at run-time by leaking the preempt count,
whether by design or not, so it's certainly possile :-)
From: Dave Airlie <airlied@gmail.com> Date: 2010-10-19 20:51:00
On Tue, Oct 19, 2010 at 11:26 PM, Arnd Bergmann [off-list ref] wrote:
On Tuesday 19 October 2010, Arnd Bergmann wrote:
quoted
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
quoted
quoted
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() > 1) {
pr_err("i810 no longer supports SMP\n");
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Some research showed that Intel never support i810/i815 SMP setups,
but there was indeed one company (http://www.acorpusa.com at the time,
now owned by a domain squatter) that made i815E based dual Pentium-III
boards like this one: http://cgi.ebay.com/280319795096
Also that board has no on-board GPU enabled i815EP (P means no on-board GPU).
So I think i810 is fine.
The first person that can send me an authentic log file showing the
use of X.org with DRM on a 2.6.35 kernel with two processors on that
mainboard dated today or earlier gets a free upgrade to an AGP graphics
card of comparable or better 3D performance from me. Please include
the story how why you are running this machine with a new kernel.
i830 is harder, apparently some i865G boards support Pentium 4 with HT
and even later dual-core processors.
Also hyper-threaded 845G boards, however I'm happy to start a proper
deprecation procedure on the i830 ABI,
Its been a few years since a distro shipped with it, I think even
RHEL5 has the i915 driver enabled, so we are
probably talking RHEL4 era.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Ville Syrjälä <syrjala@sci.fi> Date: 2010-10-20 16:15:02
On Wed, Oct 20, 2010 at 06:50:58AM +1000, Dave Airlie wrote:
On Tue, Oct 19, 2010 at 11:26 PM, Arnd Bergmann [off-list ref] wrote:
quoted
On Tuesday 19 October 2010, Arnd Bergmann wrote:
quoted
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
quoted
quoted
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() > 1) {
pr_err("i810 no longer supports SMP\n");
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Some research showed that Intel never support i810/i815 SMP setups,
but there was indeed one company (http://www.acorpusa.com at the time,
now owned by a domain squatter) that made i815E based dual Pentium-III
boards like this one: http://cgi.ebay.com/280319795096
Also that board has no on-board GPU enabled i815EP (P means no on-board GPU).
A quick search seems to indicate that an i815E variant also existed.
--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html