Re: [PATCH 1/2]Blackfin archtecture patche for 2.6.16
From: Andrew Morton
Date: Tue Mar 21 2006 - 06:15:26 EST
"Luke Yang" <luke.adi@xxxxxxxxx> wrote:
> This is the Blackfin archtecture patch for kernel 2.6.16.
There are few practical issues we need to be concerned about with new
- We don't want to be putting 44000 lines of new code in the kernel and
then have it rot. Who will support this in the long-term? What
resources are behind it? IOW: what can you say to convince us that it
The lack of a MAINTAINERS entry doesn't inspire confidence..
- How widespread/popular is the blackfin? Are many devices using it?
How old/mature is it? Is it a new thing or is it near end-of-life?
It's a cost/benefit thing. It costs us to add code to the kenrel. How
many people would benefit from us doing that?
- Are easy-to-install x86 cross-build packages available? If not, are
there straightforward instructions anywhere to guide people in generating
a cross-build setup?
OK, blackfin.uclinux.org seems to have that. Does binutils support
- A lot of this code appears to come from Analog Devices, but you don't ;)
We'd need to see some sort of authorisation from the original authors
for the inclusion of their code. Preferably in the form of
As I said, 44kloc ;)
- Do you really need to support old_mmap()?
- It would be preferable to use the generic IRQ infrastructure in kernel/irq/
- Too much use of open-coded `volatile'. The objective should be to have
zero occurrences in .c files. And volatile sometimes creates suspicion
even when it's used in .h files.
- bug: coreb_ioctl() does copy_from_user() and down() inside spinlock.
- err, coreb_ioctl() does down(&file->f_dentry->d_inode->i_sem); but
that's a mutex now, so I assume that's actually dead code?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/