several new operations have been added to super_operations, presumably
as part of the reiserfs merge. write_super_lockfs and unlockfs are
never called. can we remove them?
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe
Eric S. Raymond wrote:
Reasoned objections can change my behavior. Grunting territorial
challenges at me will not. You have two options: (1) persuade Linus
that the whole CML2 thing is a bad idea and should be dropped, or (2)
work with me to correct any errors I have made and improve the
On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote:
The transaction(2) syscall can be just as easily abused as ioctl(2) in
this respect.
But read() and write() cannot.
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line unsubscribe
On Tue, May 22, 2001 at 08:49:04AM +0100, Alan Cox wrote:
For _devices_, though? I don't expect my mouse to work if gpm and xfree
both try to consume device events from the same filp. Heck, it doesn't
even work when they try to consume events from the same inode :-) I think
this is a
On Tue, May 22, 2001 at 04:31:37PM +0100, Alan Cox wrote:
`the class of devices in question' was cryptographic devices, and possibly
other transactional DSPs. I don't consider audio to be transactional.
in any case, you can do transactional things with two threads, as long
as they each
On Mon, May 21, 2001 at 06:13:18PM -0700, Linus Torvalds wrote:
Nope. You can (and people do, quite often) share filps. So you can't
associate state with it.
For _devices_, though? I don't expect my mouse to work if gpm and xfree
both try to consume device events from the same filp. Heck, it
On Tue, May 22, 2001 at 02:22:34AM +0200, Ingo Oeser wrote:
ioctl has actually 4 semantics:
command only
command + read
command + write
command + rw-transaction
Separating these would be a first step. And yes, I consider each
of them useful.
command only: reset drive
echo 'reset'
On Sat, May 19, 2001 at 05:25:22PM +0100, Alan Cox wrote:
Only to an English speaker. I suspect Quebec City canadians would prefer a
different command set.
Should we support `pas387' as well as `no387' as a kernel boot parameter
then? Face it, a sysadmin has to know the limited subset of
On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote:
Pheeew... Could you spell about megabyte of stuff in ioctl.c?
No.
$ ls -l arch/*/kernel/ioctl32*.c
-rw-r--r--1 willywilly 22479 Jan 24 16:59 arch/mips64/kernel/ioctl32.c
-rw-r--r--1 willywilly 109475 May
On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote:
clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add
unopened descriptors. I.e. no IO until you open it (turning the thing into
opened one), but we can do lookups (move to child), we can clone and
kill them and
On Sat, Sep 09, 2000 at 03:18:57PM +0200, Andreas Gruenbacher wrote:
Hi,
What are the intended semantics for a remount:
(a) equivalent to a mount, resetting all mount options that
might be set
(b) change mount options relative to the current mount Aoptions
For ext2, the 2.2.17
On Thu, Aug 31, 2000 at 12:26:29AM +0200, Rogier Wolff wrote:
int mr (unsigned int rate, int r)
{
int e = 16+9;
static int round[4]={0, 0, 0x, 0x8000};
if (!rate) return 0;
for (; rate 0xfc00 ;rate = 1, e++);
for (;!(rate 0xfe00);rate = 1,
hi tigran. can we add some more entries to dontdiff?
*.ver
sm_tbl_*.h
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Does anyone actually want /proc/locks to stay? The data structure
which allows it to be generated is now only used by the code to print
out /proc/locks. If it could be deleted, a lot of code and data pointers
could go away. I don't think any program depends on its existance and
it's a pretty
On Sun, Oct 01, 2000 at 12:29:27AM +0100, Alan Cox wrote:
Does anyone actually want /proc/locks to stay? The data structure
I'd like a way to view the locks that exist - its useful for debugging
weird app stuff
out /proc/locks. If it could be deleted, a lot of code and data pointers
On Sun, Oct 01, 2000 at 12:55:30AM +0100, Alan Cox wrote:
When debugging this kind of problem, you're not interested in the
non-conflicting locks, only the ones which are blocked waiting for
another lock, right?
All I care about is what locks are currently in force in the system. So for
On Sat, Sep 30, 2000 at 08:23:37PM -0500, Peter Samuelson wrote:
[Matthew Wilcox]
if fcntl took a 4th argument specifying the length of the buffer, i'd
recommend a F_GETLKS fcntl. a horrid work around for this would be
that the first 4 bytes of the buffer pointed to by the third
diff -urNX dontdiff linux-2.4.2/Documentation/DocBook/Makefile
linux-willy/Documentation/DocBook/Makefile
--- linux-2.4.2/Documentation/DocBook/Makefile Sat Feb 3 13:43:55 2001
+++ linux-willy/Documentation/DocBook/Makefile Sat Mar 3 18:01:07 2001
@@ -82,6 +82,8 @@
This is just the kernel-doc parts; the .tmpl file entry is missing until
i get the chance to sync up with Alan again.
--- linux-2.4.2/include/asm-i386/bitops.h Wed Feb 21 17:09:56 2001
+++ linux-willy/include/asm-i386/bitops.h Mon Mar 5 00:39:28 2001
@@ -23,6 +23,16 @@
#define
On Wed, Mar 14, 2001 at 10:26:50AM -0700, Andreas Dilger wrote:
Let me put it that way: I don't understand why (if it is useful at all)
it is done in the fs. Looks like a wrong level...
For the same reason that the UUID and LABEL are stored in the superblock:
you want this infomation kept
I built 2.4.0-test10 for my laptop and got caught out by `make config'.
When I typed `Pentium-II' for my CPU type, it selected Pentium-III and
my kernel wouldn't boot. To prevent errors of this type, please apply
this patch. As a bonus, `Celeron' will now work as an answer too.
Please apply.
find_vma_prev doesn't return a pointer to the `prev' vma if the address
is greater than the last existing vma. This doesn't matter unless you're
on a PA-RISC machine :-)
This rewrite should speed up make find_vma_prev simpler, as well as
fixing the previous behaviour.
--- linux-t10/mm/mmap.c
doh, i'm a moron.
-- This is a copy of the message --
Date: Thu, 28 Dec 2000 14:51:25 +
From: Matthew Wilcox [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [PATCH] kmalloc(HIGHUSER) crashes
The slab cache accepts the __GFP_HIGHMEM flag, but it will then die
On Tue, Jan 02, 2001 at 01:03:48AM -0800, David S. Miller wrote:
If you require an external agent (f.e. your spinlock) because you
cannot implement xchg with a real atomic sequence, this breaks the
above assumptions.
We really can't. We _only_ have load-and-zero. And it has to be 16-byte
On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote:
Remove dead CONFIG_BINFMT_JAVA symbol.
Please don't do this, it just makes merging our patches with Linus harder.
This has already been done in our tree since Feb 1. In fact, please
don't touch anything in the tree which is PA
On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote:
What is the right procedure for doing changes like this? Is "don't
touch that tree" a permanent condition, or am I going to get a chance
to clean up the global CONFIG_ namespace after your next merge-down?
Our current status is
On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote:
Doesn't this seem a little like the problems occurring with lvm right now?
A separate tree maintained with the maintainers not wanting others
submitting patches that conflict with their particular tree? It seems
that any project
On Fri, Apr 20, 2001 at 11:15:12AM -0500, Bob McElrath wrote:
This may be a dumb question, but is there some place where the arch
maintainers are listed? Where the arch-specific trees are kept? Where
would I go to get the latest set of relevant patches for alpha?
http://www.kernel.org/ has
On Fri, Apr 20, 2001 at 02:00:00PM -0500, Jeff Dike wrote:
[EMAIL PROTECTED] said:
http://www.kernel.org/ has a list of architecture websites. Also the
CREDITS / MAINTAINERS files tend to list the people who are involved.
Except it's restricted to processor ports, which would leave you
On Fri, Apr 20, 2001 at 03:47:43PM -0400, Eric S. Raymond wrote:
CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig
Not used in code anywhere. Can you get rid of this one?
Code not merged yet.
CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c
CONFIG_FUNC_SIZE:
Something which came up in one of the hallway discussions at the
kernelsummit was that a lot of the architecture maintainers would find
it more convenient if the arch-specific header files were moved from
include/asm-$ARCH to arch/$ARCH/include. Since we use a symlink _anyway_,
no global
can I assume that a member of a structure of type atomic_t is 0 after
using memset to zero on the structure ?
You must not do this. use atomic_init instead. on parisc, the locked value
of a spinlock is 0, so no more updates to that atomic value would ever work.
--
Revolutions do not
On Fri, Jun 15, 2001 at 01:10:00AM -0400, Alexander Viro wrote:
+static inline void write_super(struct super_block *sb)
+{
+ lock_super(sb);
+ if (sb-s_root sb-s_dirt)
When I first looked at this, I thought it was a typo. I don't think we
should
On Fri, Mar 23, 2001 at 09:56:47AM -0700, Bryan Henderson wrote:
There's a lot of cool simplicity in this, both in implementation and
application, but it leaves something to be desired in functionality. This
is partly because the price you pay for being able to use existing,
well-worn
On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
I vaguely remember a discussion about this a few months back.
If I remember, the reasoning was it would unnecessarily slow
down smaller systems that would never have block devices in
the 4-28T range attached.
4k page size * 2GB =
On Mon, Mar 26, 2001 at 08:01:21PM +0200, Manfred Spraul wrote:
drivers/block/ll_rw_blk.c, in submit_bh()
bh-b_rsector = bh-b_blocknr * (bh-b_size 9);
But it shouldn't cause data corruptions:
It was discussed a few months ago, and iirc LVM refuses to create too
large volumes.
Ah yes,
On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
What do you mean by problems 5 years down the road? The real issue is that
this 32-bit block count limit affects composite devices like MD RAID and
LVM today, not just individual disks. There have been several postings
I have
On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
So...is it the plan, or has it been though about -- 'abstracting'
block numbes as a typedef 'block_nr', then at compile time
having it be selectable as to whether or not this was to
be a 32-bit or 64 bit quantity -- that way older
On Mon, Apr 16, 2007 at 06:11:30PM +0200, Andreas Gruenbacher wrote:
+static inline int
+nfsd_do_create(struct inode *dir, struct dentry *child, struct vfsmount *mnt,
+int mode)
+{
+ struct nameidata nd = {
+ .dentry = child,
+ .mnt = mnt,
+ };
On Thu, Apr 19, 2007 at 07:39:59PM +0300, Dan Aloni wrote:
On Thu, Apr 19, 2007 at 05:47:43PM +0200, Jan-Benedict Glaw wrote:
Where's the user?
A privately maintained kernel driver.
Do we _must_ have in-tree users? I'd consider the change for completion's
sake.
I agree with Dan -- if
On Sat, Mar 17, 2007 at 08:59:05PM +1100, Paul Mackerras wrote:
... but wouldn't work on 32-bit powerpc. :( We would end up with a
pad argument between fd and offset, giving 7 arguments in all
(counting the loff_t's as 2), but we only support 6.
Ditto mips and parisc.
-
To unsubscribe from
On Fri, Mar 16, 2007 at 05:17:04PM +0100, Heiko Carstens wrote:
+asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len)
e.g.
asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len, int mode)
would work even on s390 ;)
How about:
asmlinkage long
On Sun, Mar 18, 2007 at 08:16:19PM +0100, Arjan van de Ven wrote:
the problem with the people who say they want forced umount is.. that
most of the time they either want
1) get rid of the namespace entry
or
2) want to stop any and all IO to a certain device/partition
There is a third
On Sun, Apr 08, 2007 at 09:16:59PM -0700, [EMAIL PROTECTED] wrote:
REISER4 FOR INCLUSION IN THE LINUX KERNEL.
Fuck off. Cheerleading like this only hurts your cause.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Tue, Apr 10, 2007 at 05:45:07PM -0400, Robert P. J. Day wrote:
that works fine if you're defining a single spinlock, but what do you
do in cases like this:
arch/sparc/lib/atomic32.c: [0 ... (ATOMIC_HASH_SIZE-1)] =
SPIN_LOCK_UNLOCKED
that is, when you're assigning an array of
Personally, I've lost count of the number of times I've *not* reported a
bug/oops just because of the NVidia users this means you statement, only
to have the exact same issue reported several weeks/months later by somebody
who's able to replicate it with an untainted kernel.
If you can
On Mon, Jan 07, 2008 at 06:04:25PM -0500, [EMAIL PROTECTED] wrote:
Theoretically, at least. Sometimes, in the real world, other constraints
enter into it...
So you're saying that you can't find reliable ways to reproduce problems
on demand? Those are some of the lower quality bug reports, so
On Tue, Jan 08, 2008 at 01:16:06PM -0700, Matthew Wilcox wrote:
On Tue, Jan 08, 2008 at 09:03:13PM +0100, Paolo Ciarrocchi wrote:
Yes of course, I've been silly in didn't verify whether the file compile
but I would appreciate to know whether I'm on the right track or not.
Well ... you're
On Tue, Jan 08, 2008 at 08:58:04PM +0100, Paolo Ciarrocchi wrote:
-static const struct file_operations rtc_fops = {
+static long rtc_fioctl(struct file_operations rtc_fops)
+{
+ lock_kernel();
.owner = THIS_MODULE,
You should probably restrict yourself to files that you
On Tue, Jan 08, 2008 at 09:03:13PM +0100, Paolo Ciarrocchi wrote:
On Jan 8, 2008 9:00 PM, Matthew Wilcox [EMAIL PROTECTED] wrote:
On Tue, Jan 08, 2008 at 08:58:04PM +0100, Paolo Ciarrocchi wrote:
-static const struct file_operations rtc_fops = {
+static long rtc_fioctl(struct
On Thu, Jan 10, 2008 at 12:53:04PM +0530, Nikanth Karthikesan wrote:
default:
printk(%s: Unimplemented ioctl 0x%x\n, tape-name, cmd);
+ unlock_kernel();
return -EINVAL;
Surely a bug ... shouldn't this return -ENOTTY?
--
Intel are signing my
On Thu, Jan 10, 2008 at 02:47:33AM +, Matthew Hall wrote:
I am using the Supermicro H8DCE motherboard. Some (not all) of the SATA
channels quit working due to some kind of resource conflict when I
upgrade to any kernel above 2.6.20.xx series, in my case I am running
2.6.20.21 SMP x86_64
On Thu, Jan 10, 2008 at 09:01:41PM +0530, Nikanth Karthikesan wrote:
On Thu, 2008-01-10 at 16:01 +0100, Jiri Kosina wrote:
On Wed, 9 Jan 2008, Alan Cox wrote:
default:
printk(%s: Unimplemented ioctl 0x%x\n, tape-name,
cmd);
+
On Thu, Jan 10, 2008 at 07:59:44PM +0100, Andi Kleen wrote:
Really, all this is doing is open coding what the ioctl handler is doing
anyway, isn't it? in which case, why bother to change it at all?
Because once it's open coded it is visible and can then be eliminated.
Does SCSI need the
On Thu, Jan 10, 2008 at 08:32:27PM +0100, Andi Kleen wrote:
Not many really in the core kernel. Hardly any. Grep for
lock_kernel to be sure, but there is not much.
It's mostly drivers that still need it.
How about the low level SCSI drivers that might called from the high
level SCSI
On Fri, Jan 11, 2008 at 05:09:52PM +0530, Nikanth Karthikesan wrote:
The random_ioctl is registered as an ioctl function but it does not
require BKL to be held when called. Changing it as an unlocked_ioctl
function.
Signed-off-by: Nikanth Karthikesan [EMAIL PROTECTED]
Acked-by: Matthew
On Fri, Jan 11, 2008 at 11:02:29AM -0800, Greg KH wrote:
Can you send me a follow-on patch that documents this in
Documentation/ABI please.
Greg, if you integrate Ivan's patch, you don't need Arjan's patch.
--
Intel are signing my paycheques ... these opinions are still mine
Bill, look, we
On Fri, Jan 11, 2008 at 01:28:30PM -0800, Linus Torvalds wrote:
On Fri, 11 Jan 2008, Matthew Wilcox wrote:
Did I miss a bug report? The only problems I'm currently aware of are
the ones where using MMCONFIG during BAR probing causes a hard lockup on
some Intel machines, and the ones
On Fri, Jan 11, 2008 at 12:27:06PM -0800, Linus Torvalds wrote:
On Fri, 11 Jan 2008, Matthew Wilcox wrote:
Ivan's patch doesn't start enabling MMCONFIG in more places than we
currently do. It makes us use conf1 accesses for all accesses below
256 bytes. That fixes all known problems
On Fri, Jan 11, 2008 at 11:45:24AM -0800, Greg KH wrote:
On Fri, Jan 11, 2008 at 11:40:02AM -0800, Arjan van de Ven wrote:
Personally I absolutely don't agree with that.
Ivan's patch is another attempt to make MMCONFIG work somewhat better,
but does not provide the explicit opt-in that I
On Fri, Jan 11, 2008 at 11:58:23AM -0800, Linus Torvalds wrote:
On Fri, 11 Jan 2008, Matthew Wilcox wrote:
So your argument is that MMCONFIG sucks, therefore Linux has to have a
horrible interface to extended PCI config space?
What's *your* point?
MMCONFIG is known broken. If we ever
On Fri, Jan 11, 2008 at 01:12:12PM -0800, Linus Torvalds wrote:
On Fri, 11 Jan 2008, Matthew Wilcox wrote:
But they can't. We limit the size they can access to 256 bytes, unless
the kernel probed address 256 and it worked.
Umm. Probing address 256 (or *any* address) using MMCONFIG
On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote:
btw this is my main objection to your patch; it intertwines the conf1 and
mmconfig code even more.
When (and I'm saying when not if) systems arrive that only have MMCONFIG
for some of the devices,
we'll have to detangle this
On Sat, Jan 12, 2008 at 08:42:48PM -0800, Arjan van de Ven wrote:
Wanne bet there'll be devices that screw this up? THere's devices that even
screwed
up the 64-256 region after all.
I don't know if they 'screwed it up'. There are devices that misbehave
when registers are read from pci config
On Sat, Dec 29, 2007 at 12:12:19AM +0300, Ivan Kokshaysky wrote:
On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote:
One thing that could be changed in pci_cfg_space_size() is to avoid
making a special case for PCI-X 266MHz/533Mhz (assume cfg_size == 256
for such devices too,
On Sun, Jan 13, 2008 at 06:08:05PM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2008-01-12 at 17:40 +0300, Ivan Kokshaysky wrote:
Actually I'm strongly against Arjan's patch. First, it's based on
assumption that the MMCONFIG thing is sort of fundamentally broken
on some systems, but none of
On Sun, Jan 13, 2008 at 12:24:15AM -0700, Matthew Wilcox wrote:
Here's a patch (on top of Ivan's) to improve things further.
Oops. I forgot to check the ordering of mmconfig vs direct probing, so
that patch would end up just using mmconfig for everything. Not what we
want. Also, there's three
On Sun, Jan 13, 2008 at 10:41:24AM -0800, Arjan van de Ven wrote:
Note: There is not a 100% overlap between need and will not be used in
the patches that use legacy for 256. In the other patches posted,
extended config space will be used in cases where it won't be with my
patch. (Most
If CONFIG_KPROBES is set, we get the error during build:
kernel/kprobes.c:1057: error: __ksymtab_jprobe_return causes a section
type conflict
This is because ia64 defines a static inline jprobe_return which kprobes
attempts to EXPORT_SYMBOL.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED
On Mon, Jan 14, 2008 at 02:32:13PM +0100, Mathieu Segaud wrote:
+#include linux/smp_lock.h
You don't add any uses of lock_kernel() and there are none in the
driver currently.
- .owner= THIS_MODULE,
- .open = ch_open,
- .release = ch_release,
- .ioctl
one tab
too many for the first three lines.
Please correct that one, and then add my:
Reviewed-by: Matthew Wilcox [EMAIL PROTECTED]
Thanks!
--
Intel are signing my paycheques ... these opinions are still mine
Bill, look, we understand that you're interested in selling us this
operating system
On Tue, Dec 04, 2007 at 05:26:28AM +0100, Nick Piggin wrote:
+static void copy_to_brd(struct brd_device *brd, const void *src,
+ sector_t sector, size_t n)
+{
+ struct page *page;
+ void *dst;
+ unsigned int offset = (sector (PAGE_SECTORS-1)) SECTOR_SHIFT;
() and raw_pci_write(). This is
a better interface for ACPI, ia64 and now x86.
Make pci_raw_ops private to the x86 arch, and use it to implement
raw_pci_read/write. Add a raw_pci_ext_ops for extended config space.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
diff --git a/arch/ia64/pci/pci.c b/arch
On Tue, Jan 15, 2008 at 12:04:09PM +0900, K.Tanaka wrote:
I would like to introduce a SCSI fault injection framework using SystemTap.
Currently, kernel has Fault-injection framework and Faulty mode for md,
which can also be used for testing the error handling. But, they could
only produce
On Thu, Sep 13, 2007 at 02:21:07PM +0800, Shaohua Li wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8833
We write 0x to BARs to detect BAR size, this will change BAR
base to 0xfxx depends on BAR size. In the bug, PCI MCFG base address
is 0xf400. One PCI device (gfx) has a
On Thu, Sep 13, 2007 at 03:24:46PM +0800, Shaohua Li wrote:
On Thu, 2007-09-13 at 01:31 -0600, Matthew Wilcox wrote:
You missed the part where we have to avoid doing this for host bridges ...
http://marc.info/?l=linux-kernelm=118809338631160w=2
(I believe it's now queued in Greg's
On Thu, Sep 13, 2007 at 03:56:43PM +0800, Bryan Wu wrote:
+/* Not relevant on no-mmu */
I thought this list seemed a little long, so I investigated a couple
of them. mbind makes sense (it's only implemented for NUMA ... a NUMA
embedded platform? not the kind which runs applications that use
On Sun, Sep 16, 2007 at 03:13:55PM +0400, Ivan Kokshaysky wrote:
Another possible solution is not to use mmconfig for bar sizing at all,
if it's *that* broken. It would be more complicated though, since it
probably requires changes to all architectures.
I don't think it would be that
On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote:
I'm still not sold on this idea at all. I'm really betting that there
is a lot of incorrect acpi slot information floating around in machines
and odd things will show up in these slot entries.
Is that the end of the world? Instead of
On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote:
It's a 540MByte download over a slow link for everyone else.
Where do you get this number from?
$ du -sh .git/objects/pack/
249M.git/objects/pack/
$ du -sh .git/objects/
253M.git/objects/
ie about half what you claim.
--
Intel
On Tue, Nov 13, 2007 at 01:43:53PM -0500, Mark Lord wrote:
Matthew Wilcox wrote:
ie about half what you claim.
..
No, it's from earlier in this very thread:
Adrian Bunk wrote:
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
..
mkdir t
cd t
git
On Tue, Nov 13, 2007 at 01:48:15PM -0600, Linas Vepstas wrote:
On Mon, Nov 12, 2007 at 05:13:36PM -0700, Alex Chiang wrote:
+ slot-name = kmalloc(8, GFP_KERNEL);
+ sprintf(slot-name, fake%d, count++);
Please use snprintf to avoid buffer overruns!
Or, since kmalloc can return a 32-byte
On Tue, Nov 13, 2007 at 01:56:46PM -0600, Linas Vepstas wrote:
On Mon, Nov 12, 2007 at 05:14:47PM -0700, Alex Chiang wrote:
+/* pci_slot represents a physical slot */
+struct pci_slot {
+ struct pci_bus *bus;/* The bus this slot is on */
+ struct pci_slot *next;
On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote:
Ok, again, I want to see the IBM people sign off on this, after testing
on all of their machines, before I'll consider this, as I know the IBM
acpi tables are odd.
That seems a little higher standard than patches are normally held to.
On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote:
/sys/bus/pci/slots
/sys/bus/pci/slots/control
/sys/bus/pci/slots/control/remove_slot
/sys/bus/pci/slots/control/add_slot
/sys/bus/pci/slots/0001:00:02.0
/sys/bus/pci/slots/0001:00:02.0/phy_location
Ugh. Almost two years ago,
On Tue, Nov 13, 2007 at 02:56:05PM -0800, Greg KH wrote:
Why not just use the code in the linux firmware kit that does this
already today from userspace (thanks to Kristen for pointing this out to
me on irc.)?
So then we have something that works on ACPI-based machines. Who will
add support
On Tue, Nov 13, 2007 at 03:33:14PM -0800, Kristen Carlson Accardi wrote:
As far as being able to retrieve the slot number (which it seemed from
the HP manageablity application perspective is the goal here), that
information is available from userspace as well for at least standard PCI
and pcie
On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote:
Finally they replied and asked to rediff it against their
git tree. I did that and sent patches back. No reply since then.
And mind you, the patch is not trying to do anything
complex, it mostly moves code around, removes
On Wed, Nov 14, 2007 at 02:07:56AM +0100, Andi Kleen wrote:
It's not only complexity. Each new sysfs entry costs memory.
Memory is not free. There should be always a good reason for those.
It's not a lot of memory; it's one directory and a couple of files for
each PCI slot in the system. Even
On Wed, Nov 14, 2007 at 03:53:15PM +0100, Ingo Molnar wrote:
By the way: Reverting commit 6f5391c283d7fdcf24bf40786ea79061919d1e1d
makes the same cd medium readable again on v2.6.24-rc2-409-g9418d5d.
nice - that commit should then be reverted.
We're investigating; see bugzilla 9370.
On Wed, Nov 14, 2007 at 03:35:33PM +0100, Andi Kleen wrote:
It becomes much more when someone does a find /sys. dentries are
expensive. They eventually can get pruned again, but it's still
costly to do that.
Again, if this is a big concern for you, there are better places to look
at for
On Wed, Nov 14, 2007 at 04:08:01PM +0100, Andi Kleen wrote:
Whoever is proposing a feature has the burden to justify that
its usefulness is larger than the overhead/cost it adds.
Doesn't seem to be the case with this one so far.
Huh? There are half a dozen people who think it does, and half
On Wed, Nov 14, 2007 at 12:37:29PM -0700, Alex Chiang wrote:
Register one slot per slot, rather than one slot per function.
Change the name of the slot to fake%d instead of the pci address.
+#define SLOT_NAME_SIZE KOBJ_NAME_LEN
Defined, then never used ... how about s/KOBJ_NAME_LEN/8/, then
On Mon, Nov 19, 2007 at 04:35:23PM +1100, Benjamin Herrenschmidt wrote:
The other one I'm hitting now is that the SCSI layer nowadays embeds the
'nowadays'? It has always been so.
sense_buffer inside the scsi_cmnd structure without any kind of
alignment whatsoever. I've been hitting
On Mon, Nov 19, 2007 at 11:19:00AM -0500, David Ronis wrote:
The current main Makefile incorrectly identified my ld as one that
supports --build-id (it didn't). The problem is fixed by upgrading to
the latest binutils, version 2.18, which does, but somehow I suspect
that this wasn't what was
On Mon, Nov 19, 2007 at 10:19:12AM -0800, Greg Kroah-Hartman wrote:
2.6.22-stable review patch. If anyone has any objections, please let us
know.
Makes sense to backport this.
Acked-by: Matthew Wilcox [EMAIL PROTECTED]
--
Intel are signing my paycheques ... these opinions are still mine
On Mon, Dec 17, 2007 at 08:48:03PM -0800, Joe Perches wrote:
diff --git a/MAINTAINERS b/MAINTAINERS
index 9507b42..690f172 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3758,13 +3758,6 @@ W:
http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/
T: git
On Wed, Dec 19, 2007 at 10:48:27AM +0200, Filippos Papadopoulos wrote:
Would it be better to open a bug report at bugzilla?
No, it wouldn't. Bugzilla is a place where bug reports go to be
ignored. Witness 9370 where despite my best efforts to move discussion
to the mailing list, it's been
On Wed, Dec 19, 2007 at 10:50:40AM -0600, James Bottomley wrote:
So, to get the best of both worlds, file a bugzilla and note the bugid.
Then email a complete report to the relevant list, but add [BUG bugid]
to the subject line and cc [EMAIL PROTECTED] If you do
this, bugzilla will keep track
On Thu, Dec 20, 2007 at 09:22:05AM -0800, Greg KH wrote:
The one device we know about that throws exceptions is the 830M/MG
graphics chip. This chip passes the read-compare test, so the code
merrily advances to bus sizing. When the bus sizing code writes the
BAR at offset 0x18 in this
1 - 100 of 8399 matches
Mail list logo
