On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
> One of the options is to even ship the firmware in the kernel tarbal but
> from a separate directory with a clear license clarification text in it.
I think that's what we should do. I currently don't have any firmware
requiring d
On Thu, Apr 07, 2005 at 05:34:56AM -0400, Jeff Garzik wrote:
> >For tg3 a transition period shouldn't be needed as firmware loading
> >is only needed on old/buggy hardware which is not the common case.
> >Or to support advanced features which can be disabled.
>
> TSO firmware is commonly used thes
On Thu, Apr 07, 2005 at 11:46:27AM +0200, Hannes Reinecke wrote:
> Hi all,
>
> /proc/scsi/scsi currently has a very dumb implementation of the seq_file
> api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
> large amount of devices are connected.
/proc/scsi/scsi is deprecated and
On Thu, Apr 07, 2005 at 01:21:23PM +0200, Hannes Reinecke wrote:
> > /proc/scsi/scsi is deprecated and even only compiled in if
> > "legacy /proc/scsi/ support" is enabled. Please move over to lssci which
> > is using sysfs ASAP.
> >
> Ah. And that's enough reason for it not to work properly?
> D
On Tue, Apr 05, 2005 at 11:46:41AM -0400, Benjamin LaHaise wrote:
> On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote:
> > IOW: the current semaphore implementations really all need to die, and
> > be replaced by a single generic version to which it is actually
> > practical to add ne
On Thu, Apr 07, 2005 at 09:18:38AM -0400, James Bottomley wrote:
> On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
> > On Wed, Apr 06 2005, James Bottomley wrote:
> > > My proposal is to correct this by moving the data back to the correct
> > > object, and make any object using it hold a refer
On Fri, Apr 08, 2005 at 12:23:46AM -0700, Jeremy Higdon wrote:
> > It works for those setups that already worked with 2.4.x, aka only a few
> > luns.
>
> Even if it's deprecated, wouldn't it be good to fix it as long as
> it's there, unless it hurts something else? Or at least fix the
> out of me
On Fri, Apr 08, 2005 at 01:10:11AM -0700, Jeremy Higdon wrote:
> Just as a sanity check, you meant "lsscsi" and not "lssci" in your original
> reply, right?
Yes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
> + cmd->request->flags |= REQ_SOFTBARRIER;
> +
> + spin_lock_irqsave(q->queue_lock, flags);
> + blk_requeue_request(q, cmd->request);
> + spin_unlock_irqrestore(q->queue_lock, flags);
>
> scsi_run_queue(q);
This exact code sequence is duplicated in the previous patch, mayb
On Mon, Apr 11, 2005 at 10:36:51PM -0700, Greg KH wrote:
> On Mon, Apr 11, 2005 at 08:24:08PM -0700, Alex Aizman wrote:
> > Common header files:
> > - iscsi_ifev.h (user/kernel events).
>
> These structures cross the user/kernel boundry? If so, they _must_ use
> the __
On Tue, Apr 12, 2005 at 12:45:14AM -0700, Greg KH wrote:
> Um, why? We've been down this road before, and for types that cross the
> boundry, we _must_ use the __ version of the kernel types, not the
> uint32_t stuff.
That's total bullshit. C99 types just work in both the kernel and userland,
wh
On Tue, Apr 12, 2005 at 05:55:01AM -0400, Jes Sorensen wrote:
> Hi Andrew,
>
> This patch provides the generic allocator needed for the ia64 mspec
> driver. Any chance you could add it to the mm tree?
>
> Thanks,
> Jes
>
> Generic allocator that can be used by device driver to manage special
>
> +#include
this will break on all plattforms except alpha and ia64.
-
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.o
On Tue, Apr 12, 2005 at 09:02:42AM -0500, Kilau, Scott wrote:
> LKML, please, do *NOT* apply this patch to the kernel!
> It will cause conflicts if our customers have both the Digi DGNC and
> IBM/Digi JSM drivers installed!
Who cares? If you're driver was written properly (which I hope for you)
i
On Tue, Apr 12, 2005 at 04:13:43PM +0400, Ihalainen Nickolay wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I compile linux-2.6.12_r2 sources with jsm support, but Digi Neo 8 is
> unsupported.
> after some code-modifications it works fine.
The patch is badly mangled, please resend w
On Tue, Apr 12, 2005 at 10:51:20AM -0400, Jes Sorensen wrote:
> >>>>> "Christoph" == Christoph Hellwig <[EMAIL PROTECTED]> writes:
>
> >> +#include
> Christoph> this will break on all plattforms except alpha and ia64.
>
> The driver i
On Tue, Apr 12, 2005 at 09:55:10AM -0500, Kilau, Scott wrote:
> We (Digi) cares.
>
> We want people to use our DGNC driver over the JSM driver in all
> cases except the 2 port model of the board.
And we (kernel developers) don't care what drivers digi wants people
to use. We empower people to us
On Tue, Apr 12, 2005 at 10:30:19AM -0500, Kilau, Scott wrote:
> However, when the copyright holder says "No, please don't add that
> code",
> and gives *GOOD* reasons why, you should respect that decision.
You didn't not give a single good reason. Only political bullshit.
> So if I don't sign of
On Tue, Apr 12, 2005 at 09:32:19PM +0200, Andreas Schwab wrote:
> On my PowerMac the internal speaker is now working, but unfortunately on
> the line-out I get nearly no output. I have pushed both the master and
> pcm control to the maximum and still barely hear anything.
Work fine for me, but I
On Tue, Apr 12, 2005 at 11:27:44PM -0400, Ricky Beam wrote:
> As an outside observer, I think he's given you plenty of reason to not
> include this "hack". You, however, appear to only want to make a mess.
Why do you consider it a mess, and what reason did you see?
The jsm driver is an effort wh
> I think you should supply a patch that makes the in-kernel driver print a
> short notice about your other driver. E.g.
>
> The foo driver is a stripped-down version of the bar driver. To get the
> additional configuration and diagnosis infrastructure, see the
> instructions on url.
>
N
On Wed, Apr 13, 2005 at 12:40:38PM +0200, Bodo Eggert <[EMAIL PROTECTED]> wrote:
> If there are checks, they should be there for a purpose,
emphasis here is on _should_
> and any sane reader will asume these checks to be nescensary.
That's a bad assumptions when you're deadling with drivers or s
On Tue, Apr 12, 2005 at 10:50:08AM -0400, Jes Sorensen wrote:
> +config MSPEC
> + tristate "Special Memory support"
> + select GENERIC_ALLOCATOR
should depend on IA64_GENERIC || IA64_SGI_SN2 because it's using sn2
functions like bte_copy
> +#define BTE_ZERO_BLOCK(_maddr, _len) \
> + b
On Wed, Apr 13, 2005 at 02:02:42AM +, Alexey Dobriyan wrote:
>
> > +Why: Replaced by ->compat_ioctl in file_operations and other method
> > + vecors.
>
> vectors ?
Yes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
On Mon, Apr 11, 2005 at 10:30:58PM -0400, linux-iscsi development team wrote:
> The linux-iscsi and open-iscsi developers would like to announce
> that they have combined forces on a single iSCSI initiator effort!
What SCM will the code be in? I must admit I really, really prefer the
SVN hosting
On Thu, Apr 14, 2005 at 09:18:32AM -0700, Dmitry Yusupov wrote:
> Consider linux-iscsi-5.x CVS branch as a "mainline". Current open-iscsi
> SVN repository is the place where all hard-core development will happen
> at least for the nearest future.
>
> I really hope sf.net will provide SVN hosting v
On Fri, Apr 15, 2005 at 02:31:00AM +0100, Matthew Wilcox wrote:
> On Fri, Apr 15, 2005 at 03:07:42AM +0200, Jesper Juhl wrote:
> > 'arg' is unsigned so it can never be less than zero, so testing for that
> > is pointless and also generates a warning when building with gcc -W. This
> > patch elimi
On Fri, Apr 15, 2005 at 12:29:08PM +0100, Matthew Wilcox wrote:
> > I think Linux only complained if we're using some typedef that actually
> > may be signed. For fcntl that 'arg' argument is unsigned and that's
> > hardcoded
> > in the ABI. So the check doesn't make sense at all.
>
> No, it wa
In article <[EMAIL PROTECTED]> you wrote:
> On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote:
>> Christoph Hellwig wrote:
[my voice was snipped here]
>> Yes, I should have limited myself to pre-egcs versions.
>
> Huh?
>
> It's been possible to h
On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote:
> Alan Cox <[EMAIL PROTECTED]>:
> > > I don't want to do (a); it conflicts with my design objective of
> > > simplifying configuration enough that Aunt Tillie can do it. I won't
> > > do that unless I see a strong consensus that it
On Sun, May 13, 2001 at 06:36:11PM +0100, David Woodhouse wrote:
> IMHO, no 64-bit architecture code should provide translation functions for
> ioctls from 32-bit binaries.
>
> This is now a sufficiently common requirement that it shouldn't be repeated
> by all architectures that require it - it
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote:
> Alan, it sounds very much like you just said something stupid. This
> seems sufficiently unlikely that I am shaking my head in disbelief and
> fingernailing wax out of both ears (and if you think doing both those
> things at once
On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote:
> Michael Meissner <[EMAIL PROTECTED]>:
> > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > > Aunt Tillie shouldn't try to manually configure a kernel.
> >
> > Ummm
On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote:
> Jes Sorensen wrote:
>
> > Telling them to install an updated gcc for kernel compilation
> > is a necessary evil, which can easily be done without disturbing the
> > rest of the system. Updating the system's python installation is not a
Hi all,
this are the sound locking fixes for es1371. While it is inspired by the
trident fixes it contains some changes over it:
o es1371_mmap used to use lock_kernel to do some synchronistation,
this is superceeded by s->sem.
o remap_page_range (used in es1371_mmap) needs the mm semaph
In article <[EMAIL PROTECTED]> you wrote:
> 2.4.5-ac9
> o Add es1371 sound driver locking (Frank Davis)
It's buggy. The locking in ->read and ->write will give
double ups when a signal is pending and remove a not added waitq
when programming the dmabuf fails.
Christ
On Wed, Jun 06, 2001 at 01:41:31PM +0200, Thomas Sailer wrote:
> Christoph Hellwig schrieb:
> >
> > In article <[EMAIL PROTECTED]> you wrote:
> > > 2.4.5-ac9
> >
> > > o Add es1371 sound driver locking (Frank Davis)
> >
Hi Joerg,
In article <[EMAIL PROTECTED]> you wrote:
> Hi,
>
> I am trying to integrate binfmt_xout.c into kernel 2.4 as part of the
> linux-abi project (formerly known as iBCS). For old Xenix 286 binaries the
> lcall7 gate needs to part of the LDT.
>
> In kernels 2.0 sys_modify_ldt(0,...) used
In article <[EMAIL PROTECTED]> you wrote:
> On dual-CPU machines the speedups are as follows: my version
> is 1.88 faster than the sequential one on IRIX, 1.81 times on Solaris,
> 1.8 times on OSF/1, 1.43 times on Linux 2.2.x and 1.52 times on Linux 2.4
> kernel. Why are the numbers on Linux machi
On Tue, Jun 12, 2001 at 01:07:11PM -0600, [EMAIL PROTECTED] wrote:
> Hello,
>
> due to the nature of the problem (a pairwise mutual alignment of n
> sequences results in mx. n^2 alignments which can each be done in a
> separate thread), I need to create and destroy the threads frequently.
>
> I
In article <[EMAIL PROTECTED]> you
wrote:
> For heavy threading, try a user-level threads package.
Sure, userlevel threading is the best way to get SMP-scalability...
--
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe l
On Mon, Jul 11, 2005 at 03:57:26PM +0200, Andrew Victor wrote:
> > Or written a perl script to reprocess them into something saner for
> > that matter.
>
> The issue that everybody seems to be forgetting (or ignoring) with
> changing the headers is that ALL the drivers then also need to be
> conve
On Mon, Jul 11, 2005 at 08:10:42PM -0500, Tom Zanussi wrote:
>
> Hi Andrew, can you please merge relayfs? It provides a low-overhead
> logging and buffering capability, which does not currently exist in
> the kernel.
While the code is pretty nicely in shape it seems rather pointless to
merge unt
On Sat, Jul 09, 2005 at 02:32:47PM +0200, Thomas Heinz wrote:
> Is it possible to make the DVD-RAM partitions available as device
> nodes (or at least directly mountable without the losetup hack)?
> One solution would be to make the device available as /dev/sdX and
> /dev/srX. Is that possible?
Wh
On Tue, Jul 12, 2005 at 04:29:00PM +1000, Nigel Cunningham wrote:
> People need to be able to recognise when this happens. They therefore
> need some feedback to know that the process is not hung, and to be able
> to say where it hung when it does.
this is called printk.
-
To unsubscribe from thi
On Tue, Jul 12, 2005 at 01:52:19PM +0200, Martin Schwidefsky wrote:
> Hi Andrew,
> an ugly one. The fadvise hint values for POSIX_FADV_DONTNEED and
> POSIX_FADV_NOREUSE in the kernel and the glibc differ for s390-64
> (and worse the values for s390-31 and s390-64 differ as well ..).
> The glibc alw
On Tue, Jul 12, 2005 at 11:39:20PM +0200, Adrian Glaubitz wrote:
> This little patch adds the missing function declaration
> of the deprecatated function call inter_module_get
> to the header file include/linux/module.h and the
> necessary EXPORT_SYMBOL to kernel/intermodule.c. Without
> the declar
On Wed, Jul 13, 2005 at 04:55:16PM +0200, Antonio Larrosa Jim?nez wrote:
> I'm using a SLES 9 system (kernel 2.6.5) which enables the cfq scheduler by
> default (I checked that it's really using cfq).
If you're having SLES9 problems please call Novell tech support.
-
To unsubscribe from this li
> In general, this construct:
>
> > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > -{
> > > - return sdev->online;
> > > -}
> > > -#endif
>
> is better tested as:
>
> #ifndef scsi_device_inline
> static int inline s
On Thu, Jul 14, 2005 at 04:50:01PM +0300, Yura Pakhuchiy wrote:
> 2005/7/14, Nathan Scott <[EMAIL PROTECTED]>:
> > On Wed, Jul 13, 2005 at 06:22:28PM +0300, Yura Pakhuchiy wrote:
> > > I found patch by Greg Ungreger to fix this problem, but why it's still
> > > not in mainline? Or it's a gcc proble
On Thu, Jul 14, 2005 at 05:45:15PM +0300, Yura Pakhuchiy wrote:
> Yes, but a lof of people use older versions of compilers and suffer
> from this bug.
> I personally was very unhappy when lost my data.
then host the patch somewhere and make sure to apply it.
-
To unsubscribe from this list: send
On Thu, Jul 14, 2005 at 08:56:58AM -0700, Daniel Walker wrote:
> This reminds me of Documentation/stable_api_nonsense.txt . That no one
> should really be dependent on a particular kernel API doing a particular
> thing. The kernel is play dough for the kernel hacker (as it should be),
> including k
On Thu, Jul 14, 2005 at 08:56:58AM -0700, Daniel Walker wrote:
> On Thu, 2005-07-14 at 07:23 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > > The whole point of using a semaphore in the pagebuf is because there
> > > > is no tracking of who "owns" the lock so we
On Sun, Jul 17, 2005 at 08:53:59AM -0500, [EMAIL PROTECTED] wrote:
> This is part [7/7] of the v9fs-2.0.2 patch against Linux 2.6.13-rc2-mm2.
>
> This part of the patch contains debug and other misc routine changes related
> to hch's comments.
Here a few if( instead if ( formatting sneaked in.
-
> +static inline void buf_check_size(struct cbuf *buf, int len)
> +{
> + if (buf->p+len > buf->ep) {
> + if (buf->p < buf->ep) {
> + eprintk(KERN_ERR, "buffer overflow\n");
> + buf->p = buf->ep + 1;
> + }
> + }
> +}
"ha
> @@ -383,9 +379,10 @@ v9fs_file_write(struct file *filp, const
> return -ENOMEM;
>
> ret = copy_from_user(buffer, data, count);
> - if (ret)
> + if (ret) {
> dprintk(DEBUG_ERROR, "Problem copying from user\n");
> - else
> + return -EFAULT
On Wed, Jul 13, 2005 at 01:23:24PM -0500, Eric Van Hensbergen wrote:
> Sorry I didn't get to these quicker - was on vacation and basically
> off-line for the past week and a half. I've made 90% of the changes
> suggested and committed them to my git tree, I'll combine the changes
> into a single p
On Thu, Jul 14, 2005 at 11:42:46PM +0200, Jan Engelhardt wrote:
> Hi,
>
>
> the following patch adds a post_setgid() security hook, and necessary dummy
> funcs.
... and why exactly would we want these?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
On Fri, Jul 15, 2005 at 09:54:40AM +0200, Jan Engelhardt wrote:
>
> >> the following patch adds a post_setgid() security hook, and necessary
> >> dummy
> >> funcs.
> >
> >... and why exactly would we want these?
>
> I am working on a sec module which, among other things, raises certain
> capab
On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>
> (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> kernel.org syncs up)
>
>
> - Added the CKRM patches. This i
On Tue, Jul 19, 2005 at 02:34:57PM +0200, Ingo Molnar wrote:
> (I do disagree with Christoph on another point: i do think we eventually
> want to change the standard semaphore type in a similar fashion upstream
> as well - but that probably has to come with a s/struct semaphore/struct
> mutex/ c
On Fri, Jul 22, 2005 at 05:58:56PM +0400, Vladimir V. Saveliev wrote:
> Hello
>
> This is implementaion of circular doubly linked parametrized list.
> It is similar to the list implementation in include/linux/list.h
> but it also provides type safety which allows to detect some of list
> manipula
On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote:
> Another vote in favor of relayfs here ...
>
> I am reminded by my good colleagues at SGI that relayfs is a key
> to the Linux Trace Toolkit (LTT), which is in turn an important
> technology for some product(s) on which SGI is working.
On Fri, Jul 22, 2005 at 10:33:21PM +0200, bert hubert wrote:
> On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote:
> > Another vote in favor of relayfs here ...
>
> At OLS the 'SystemTAP' idea was presented, which has been partially
> implemented already, and it builds on relayfs as well
On Mon, Jun 20, 2005 at 09:54:04PM +0530, Suparna Bhattacharya wrote:
> In order to allow for interruptible and asynchronous versions of
> lock_page in conjunction with the wait_on_bit changes, we need to
> define low-level lock page routines which take an additional
> argument, i.e a wait queue en
On Sun, Jul 24, 2005 at 11:17:02PM +0100, Christoph Hellwig wrote:
> On Mon, Jun 20, 2005 at 09:54:04PM +0530, Suparna Bhattacharya wrote:
> > In order to allow for interruptible and asynchronous versions of
> > lock_page in conjunction with the wait_on_bit changes, we need to
>
On Mon, Jun 27, 2005 at 11:05:02PM +0200, Christoph Hellwig wrote:
> On Wed, May 04, 2005 at 08:44:39PM +0200, Christoph Hellwig wrote:
> > additional benefit is cleaning up the ifdef mess in ppc_htab.c
> >
> >
> > Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]
On Thu, Aug 04, 2005 at 10:32:14AM -0700, Roland Dreier wrote:
> I would like to get people's reactions to moving the InfiniBand .h
> files from their current location in drivers/infiniband/include/ to
> include/linux/rdma/. If we agree that this is a good idea then I'll
> push this change as soon
On Sat, Aug 06, 2005 at 01:37:31PM +0200, Andi Kleen wrote:
> Zachary Amsden <[EMAIL PROTECTED]> writes:
>
> > i386 Transparent paravirtualization sub-arch patch #8.
> >
> > Transparent paravirtualization support for MMU operations.
> >
> > All operations which update live page table entries hav
On Sat, Aug 06, 2005 at 01:58:36PM +0200, Andi Kleen wrote:
> > > I think that patch is really ugly - it makes hacking VM on i386
> > > even more painful than it already is because the convolutes the file
> > > structure even more. Hope it is not applied.
> >
> > Especially as there's been no user
On Tue, Aug 09, 2005 at 11:23:18AM +0200, Ingo Molnar wrote:
> mine are mostly technical arguments. I just also wanted to vent away
> this slowly gathering false notion of building 'interoperability', while
> the only apparent goal seems to be to maximize benefits to the closed
> hypervisors, wh
On Tue, Aug 09, 2005 at 05:56:45PM +0200, Petr Vandrovec wrote:
> You should report problems related to the VMware at the VMware community
> forums,
> http://www.vmware.com/community/index.jspa. Most of peoples on LKML does
> not
> care about these opensource modules.
Nothing in the tarball men
Switch MD to use the kthread infrastructure, to simplify the code and
get rid of tasklist_lock abuse in md_unregister_thread. Long-term I
wonder whether workqueues wouldn't be a better choice than the
MD-specific thread wrappers for the lowlevel drivers.
Signed-off-by: Christoph Hellwig &l
Currently snsc_event for Altix systems sends SIGPWR to init (and abuses
tasklist_lock..) while the sbus drivers call execve for /sbin/shutdown
(which is also ugly, it should at least use call_usermodehelper)
With normal sysvinit both will end up the same, but I suspect the
shutdown variant, maybe w
On Tue, Aug 09, 2005 at 04:20:45PM +0100, Al Viro wrote:
> On Tue, Aug 02, 2005 at 03:18:28PM +0800, David Teigland wrote:
> > Hi, GFS (Global File System) is a cluster file system that we'd like to
> > see added to the kernel. The 14 patches total about 900K so I won't send
> > them to the list u
On Tue, Aug 09, 2005 at 05:49:43PM +0300, Pekka Enberg wrote:
> On Mon, 2005-08-08 at 11:32 -0700, Zach Brown wrote:
> > > Sorry if this is an obvious question but what prevents another thread
> > > from doing mmap() before we do the second walk and messing up num_gh?
> >
> > Nothing, I suspect.
On Wed, Aug 10, 2005 at 10:40:37AM +0300, Pekka J Enberg wrote:
> Hi David,
>
> >+ return -EINVAL;
> >+ if (!access_ok(VERIFY_WRITE, buf, size))
> >+ return -EFAULT;
> >+
> >+ if (!(file->f_flags & O_LARGEFILE)) {
> >+ if (*offset >= 0x7FFFull)
> >+
fined anywhere in the tree.
Only tested on ppc32 so far.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/arch/arm/kernel/ptrace.c
===
--- linux-2.6.orig/arch/arm/kernel/ptrace.c 2005-08-09 20:16:5
On Wed, Aug 10, 2005 at 10:33:50AM +0200, Martin Schwidefsky wrote:
> Christoph Hellwig <[EMAIL PROTECTED]> wrote on 08/10/2005 10:00:57 AM:
>
> > The sys_ptrace boilerplate code (everything outside the big switch
> > statement for the arch-specific requests) is shared b
unused and useless..
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
--- 1.3/include/asm-alpha/hdreg.h 2004-04-14 01:28:58 +02:00
+++ edited/include/asm-alpha/hdreg.h2005-03-29 23:10:51 +02:00
@@ -1 +0,0 @@
-#include
= include/asm-arm/hdreg.h 1.4 vs edited =
-
On Wed, Aug 10, 2005 at 12:30:41PM +0200, Lars Marowsky-Bree wrote:
> On 2005-08-10T08:03:09, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > > Kindly lose the "Context Dependent Pathname" crap.
> > Same for ocfs2.
>
> Would a generic implemen
On Wed, Aug 10, 2005 at 12:34:24PM +0200, Lars Marowsky-Bree wrote:
> On 2005-08-10T11:32:56, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > > Would a generic implementation of that higher up in the VFS be more
> > > acceptable?
> > No. Use mount --bind
&g
On Wed, Aug 10, 2005 at 01:02:59PM +0200, Lars Marowsky-Bree wrote:
> What would a syntax look like which in your opinion does not remove
> totally valid symlink targets for magic mushroom bullshit? Prefix with
> // (which, according to POSIX, allows for implementation-defined
> behaviour)? Somethi
On Wed, Aug 10, 2005 at 01:09:17PM +0200, Lars Marowsky-Bree wrote:
> On 2005-08-10T12:05:11, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > > What would a syntax look like which in your opinion does not remove
> > > totally valid symlink targets for magic
On Thu, Aug 11, 2005 at 12:44:34PM +0200, Roman Zippel wrote:
> No objection really, but I recently reformatted the m68k sys_ptrace() so
> it would be easier to regenerate your changes on top of this. I can do
> this for you if we can agree on to merge at least the m68k ptrace changes
> before t
On Thu, Aug 11, 2005 at 09:33:41AM -0700, Zach Brown wrote:
> ordering when multiple file systems are concerned. It doesn't record
> the ranges of the mappings involved so Lustre can't properly use its
> range locks.
That doesn't matter. Please don't put in any effort for lustre special
cases -
On Wed, Aug 10, 2005 at 10:11:45AM -0700, Paul E. McKenney wrote:
> Hello!
>
> This patch is an experiment in use of RCU for individual code paths that
> read-acquire the tasklist lock, in this case, unicast signal delivery.
> It passes five kernbenches on 4-CPU x86, but obviously needs much more
David, is that more than a debugging aid? I'm trying to get rid of
tasklist_lock users and this one looks really suspicios..
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/arch/frv/kern
On Tue, Aug 09, 2005 at 11:10:03PM +0200, Christoph Hellwig wrote:
> Currently snsc_event for Altix systems sends SIGPWR to init (and abuses
> tasklist_lock..) while the sbus drivers call execve for /sbin/shutdown
> (which is also ugly, it should at least use call_usermodehelper)
>
On Thu, Aug 11, 2005 at 10:32:03AM -0700, Richard Henderson wrote:
> On Wed, Aug 10, 2005 at 10:00:57AM +0200, Christoph Hellwig wrote:
> > The sys_ptrace boilerplate code (everything outside the big switch
> > statement for the arch-specific requests) is shared by most
> >
On Thu, Aug 11, 2005 at 11:24:23AM -0700, Greg KH wrote:
> > This patch (as536) simplifies the driver-model core by replacing the klist
> > used to store the set of devices bound to a driver with a regular list
> > protected by a mutex. It turns out that even with a klist, there are too
> > man
On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> around in I/O port space. Poking at things that don't exist causes MCAs
> on HP ia64 systems.
Maybe it should instead depend on those systems where it is ava
On Sat, Aug 13, 2005 at 11:36:55PM +0200, Henrik Brix Andersen wrote:
> Here's a patch for unifying the watchdog device node name
> to /dev/watchdog as expected by most user-space applications.
>
> Please CC: me on replies as I am not subscribed to LKML.
Please don't. misdevice.name is a descrip
On Sun, Aug 14, 2005 at 02:22:41AM +0200, Henrik Brix Andersen wrote:
> On Sun, 2005-08-14 at 01:43 +0200, Olaf Hering wrote:
> > On Sun, Aug 14, Christoph Hellwig wrote:
> > > Please don't. misdevice.name is a description of the device, and doesn't
> > > h
On Sun, Aug 14, 2005 at 11:03:24AM +0200, Olaf Hering wrote:
> On Sat, Aug 13, Chris Wedgwood wrote:
>
> > On Sun, Aug 14, 2005 at 01:43:22AM +0200, Olaf Hering wrote:
> >
> > > It is used for /class/misc/$name/dev
> >
> > Ick. I would almost suggest we change that were it not too late. I
> >
defed SUBARCH_PTRACE_SPECIAL block, but SUBARCH_PTRACE_SPECIAL
isn't defined anywhere in the tree.
This version has the arch_ptrace return value changes to long as
recommended by Richard Henderson.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/arch/arm
covered are:
- m68k: has some large ptrace changes pending, should be converted to
the common sys_ptrace later
- ia64 (native ptrace only): does some wierd stuff about finding a
different thread in the same threadgroup
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
> the problem is that the pay elsewhere is far more spread out, but not
> less. At least generally
>
> I can see the point of a copy_from_user_nocache() or something, for
> those cases where we *know* we are not going to use the copied data in
> the cpu (but say, only do DMA).
> But that shoul
On Sun, Aug 14, 2005 at 03:41:49PM +0300, Samer Sarhan wrote:
> Hi,
> I had a design problem of a Linux module (Linux 2.6.11) that lead me to do
> this:
>
> int work_fn(void* data);
> task_t my_task;
> task_t* kthread = kthread_create(work_fn, NULL, "Task 1");
> // assume kthread create was succe
On Sun, Aug 14, 2005 at 08:48:48AM -0700, Richard Henderson wrote:
> On Sun, Aug 14, 2005 at 11:35:43AM +0200, Christoph Hellwig wrote:
> > This version has the arch_ptrace return value changes to long as
> > recommended by Richard Henderson.
> ...
> > +extern int arch_p
401 - 500 of 14595 matches
Mail list logo
