Hi,
On Wed, May 23, 2001 at 01:54:15PM -0400, Alexander Viro wrote:
> On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
>
> > > But I don't want an initrd.
> > Don't be afraid of words. You wouldnt notice - it would do its
> > job and disappear just like piggyback today.
>
> Andries, initrd code is
> Besides, just on general principles, we'd better have clean interface
> for changing partitioning
It is not quite clear to me what you are arguing for or against.
But never mind - I'll leave few hours from now.
When the time is there I'll show you an implementation,
and if you don't like it, yo
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> > Andries, initrd code is _sick_.
>
> Oh, but the fact that there exists a bad implementation
> does not mean the idea is wrong. It is really easy to
> make an elegant implementation.
Andries, I've been doing cleanups of that logics (see namespac
> Andries, initrd code is _sick_.
Oh, but the fact that there exists a bad implementation
does not mean the idea is wrong. It is really easy to
make an elegant implementation.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PRO
[EMAIL PROTECTED] on 05/23/2001 08:34:44 AM
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
cc:(bcc: Wayne Brown/Corporate/Altec)
Subject: Re: [PATCH] struct char_device
>> But I don't want an initrd.
>
>Don't be afraid of words. You wouldnt no
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> > But I don't want an initrd.
>
> Don't be afraid of words. You wouldnt notice - it would do its
> job and disappear just like piggyback today.
Andries, initrd code is _sick_. Our boot sequence is not a wonder of
elegance, but that crap is the wo
> But I don't want an initrd.
Don't be afraid of words. You wouldnt notice - it would do its
job and disappear just like piggyback today.
-
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.ker
[EMAIL PROTECTED] wrote:
>
> From [EMAIL PROTECTED] Wed May 23 14:16:46 2001
>
> > It is entirely possible to remove all partition table handling code
> > from the kernel. User space can figure out where the partitions
> > are supposed to be and tell the kernel.
> > For the i
Linus Torvalds wrote:
>
> On Tue, 22 May 2001, Jeff Garzik wrote:
> >
> > IMHO it would be nice to (for 2.4) create wrappers for accessing the
> > block arrays, so that we can more easily dispose of the arrays when 2.5
> > rolls around...
>
> No.
>
> We do not create wrappers "so that we can ea
From [EMAIL PROTECTED] Wed May 23 14:16:46 2001
> It is entirely possible to remove all partition table handling code
> from the kernel. User space can figure out where the partitions
> are supposed to be and tell the kernel.
> For the initial boot this user space can be in an
> It is entirely possible to remove all partition table handling code
> from the kernel. User space can figure out where the partitions
> are supposed to be and tell the kernel.
> For the initial boot this user space can be in an initrd,
> or it could just be a boot parameter: rootdev=/dev/hda,
>
Alan writes:
The current partitioning code consists of re-reading from disk. That is
code that has to be present anyway even without an initrd since it is
needed for mounting other filesystems
I am not quite sure what you are saying here.
(For example, the "even" was unexpected.)
I
> Because we still need the partitioning code for backwards
> compatibility. There's no way I'm going to use initrd to do partition
> setup with lvmtools etc.
The current partitioning code consists of re-reading from disk. That is
code that has to be present anyway even without an initrd since i
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
>
> > why not implement partitions as simply doing block remaps
>
> Everybody agrees.
No they don't.
We had this discussion already. We all agree.
Maybe you read in "remap" something other than a simple addition
but I don't.
Jeff Garzik wrote:
> /dev/sda <-> partition_blkdev <-> /dev/disk{0,1,2,3,4}
> /dev/hda <-> partition_blkdev <-> /dev/disk{5,6,7}
I also point out that handling disk partitions as a -tiny- remapping
blkdev also has the advantage of making it easy to have a single request
device per hardware device
Linus Torvalds wrote:
>
> On Tue, 22 May 2001, Jeff Garzik wrote:
> >
> > Alan recently straightened me out with "EVMS/LVM is partitions done
> > right"
> >
> > so... why not implement partitions as simply doing block remaps to the
> > lower level device? That's what EVMS/LVM/md are doing alread
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
>
> > why not implement partitions as simply doing block remaps
>
> Everybody agrees.
No they don't.
Look at the cost of lvm. Function calls, buffer head remapping, the
works. You _need_ that for a generic LVM layer, but you sure as hell don't
need
On Tue, 22 May 2001, Jeff Garzik wrote:
>
> Alan recently straightened me out with "EVMS/LVM is partitions done
> right"
>
> so... why not implement partitions as simply doing block remaps to the
> lower level device? That's what EVMS/LVM/md are doing already.
Because we still need the partit
On Tue, 22 May 2001, Jeff Garzik wrote:
>
> IMHO it would be nice to (for 2.4) create wrappers for accessing the
> block arrays, so that we can more easily dispose of the arrays when 2.5
> rolls around...
No.
We do not create wrappers "so that we can easily change the implementation
when xxx ha
On Tue, 22 May 2001, Alexander Viro wrote:
> >which populate the "inode->dev" union pointer, which in turn is _only_
> >a cache of the lookup. Right now we do this purely based on "dev_t",
> >and I think that is bogus. We should never pass a "dev_t" around
> >without an inode, I
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> >>dev_t rdev;
>
> > Reasonable.
>
> Good. We all agree.
> (But now you see what I meant in comments about mknod.)
>
> >>kdev_t dev;
>
> > Useless. If you hope that block_device will help to solve rmmod races
>
> Yes. Why am I mistaken?
>> dev_t rdev;
> Reasonable.
Good. We all agree.
(But now you see what I meant in comments about mknod.)
>> kdev_t dev;
> Useless. If you hope that block_device will help to solve rmmod races
Yes. Why am I mistaken?
Andries
-
To unsubscribe from this list: send the line "unsubscrib
[EMAIL PROTECTED] wrote:
>
> > IMHO it would be nice to create wrappers for accessing the block arrays
>
> Last year Linus didnt like that at all. Maybe this year.
Well... the attached patch lines up into this effort and fixes
some abuses, removes redundant code and so on. Please have a second
> IMHO it would be nice to create wrappers for accessing the block arrays
Last year Linus didnt like that at all. Maybe this year.
Andries
-
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.k
> why not implement partitions as simply doing block remaps
Everybody agrees.
Andries
-
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
On Tue, May 22 2001, Jeff Garzik wrote:
> IMHO it would be nice to (for 2.4) create wrappers for accessing the
> block arrays, so that we can more easily dispose of the arrays when 2.5
> rolls around...
Agreed, in fact I have a lot of stuff that could be included in the
kcompat files for 2.4 (of
On Tue, May 22 2001, Jeff Garzik wrote:
> so... why not implement partitions as simply doing block remaps to the
> lower level device? That's what EVMS/LVM/md are doing already.
That is indeed the plan, having partitions simply being 'just another'
sector remap when submitting I/O
--
Jens Axbo
Alexander Viro wrote:
> Do we really want a separate queue for each partition? I'd rather have
> disk_struct created when driver sees the disk and list of partitions
> (possibly represented by struct block_device) anchored in disk_struct
> and populated by grok_partitions().
Alan recently straigh
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> I am not sure whether we agree or differ in opinion. I wouldn't mind
>
> /* pairing for dev_t to bd_op/cd_op */
> struct bc_device {
> struct list_headbd_hash;
> atomic_tbd_count;
> dev_t
IMHO it would be nice to (for 2.4) create wrappers for accessing the
block arrays, so that we can more easily dispose of the arrays when 2.5
rolls around...
--
Jeff Garzik | "Are you the police?"
Building 1024| "No, ma'am. We're musicians."
MandrakeSoft |
-
To unsubscribe from this
> Do we really want a separate queue for each partition?
No.
> I have a half-baked patch
Me too. (Not half-baked but brewed.) In principle the change
is trivial, but there are a few IDE issues that are presently
solved in a very low-level way (and incorrectly).
This makes the patch larger than
On Tue, 22 May 2001, Linus Torvalds wrote:
> I would much prefer a union of pointers over a pointer to a union.
>
> So I'd much rather have the inode have a
>
> union {
> struct block_device *block;
> struct char_device *char;
struct pipe_ino
From [EMAIL PROTECTED] Wed May 23 00:39:23 2001
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
>
> The operations are different, but all bdev/cdev code is identical.
>
> So the choice is between two uglies:
> (i) have some not entirely trivial amount of code twice in t
And if we are at the topic... Those are the places where blk_size[]
get's
abused, since it's in fact a property of a FS in fact and not the
property of
a particular device... blksect_size is the array describing the physical
access limits of a device and blk_size get's usually checked against it.
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
>
> The operations are different, but all bdev/cdev code is identical.
>
> So the choice is between two uglies:
> (i) have some not entirely trivial amount of code twice in the kernel
> (ii) have a union at the point where the struct operations
> is
[EMAIL PROTECTED] wrote:
>
> Martin Dalecki writes:
>
> > Erm... I wasn't talking about the DESIRED state of affairs!
> > I was talking about the CURRENT state of affairs. OK?
>
> Oh, but in 1995 it was quite possible to compile the kernel
> with kdev_t a pointer type, and I have done it severa
Martin Dalecki writes:
> Erm... I wasn't talking about the DESIRED state of affairs!
> I was talking about the CURRENT state of affairs. OK?
Oh, but in 1995 it was quite possible to compile the kernel
with kdev_t a pointer type, and I have done it several times since.
The kernel keeps growing,
[EMAIL PROTECTED] wrote:
>
> Martin Dalecki writes:
>
> > I fully agree with you.
>
> Good.
>
> Unfortunately I do not fully agree with you.
>
> > Most of the places where there kernel is passing kdev_t
> > would be entierly satisfied with only the knowlendge of
> > the minor number.
>
> My
Martin Dalecki writes:
> I fully agree with you.
Good.
Unfortunately I do not fully agree with you.
> Most of the places where there kernel is passing kdev_t
> would be entierly satisfied with only the knowlendge of
> the minor number.
My kdev_t is a pointer to a structure with device data
an
[EMAIL PROTECTED] wrote:
>
> > They are entirely different. Too different sets of operations.
>
> Maybe you didnt understand what I meant.
> both bdev and cdev take care of the correspondence
> device number <---> struct with operations.
>
> The operations are different, but all bdev/cdev code
> They are entirely different. Too different sets of operations.
Maybe you didnt understand what I meant.
both bdev and cdev take care of the correspondence
device number <---> struct with operations.
The operations are different, but all bdev/cdev code is identical.
So the choice is between tw
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
> One remark, repeating what I wrote on some web page:
> -
> A struct block_device provides the connection between a device number
> and a struct block_device_operations.
> ...
> Clearly, we also want to associate a struct char_device_operations
Alexander Viro writes:
> patch below adds the missing half of kdev_t -
> for block devices we already have a unique pointer
> and that adds a similar animal for character devices.
Very good.
(Of course I did precisely the same, but am a bit slower in
submitting things during a stable series or c
On Tue, 22 May 2001, Guest section DW wrote:
> On Tue, May 22, 2001 at 11:08:16AM -0500, Oliver Xymoron wrote:
>
> > > >+ struct list_headhash;
>
> > > Why not name consistently with the struct block_device?
> > > struct list_headcd_hash;
>
> > Because foo_ is a thr
On Tue, 22 May 2001, Guest section DW wrote:
> One often has to go through all occurrences of a variable or
> field of a struct. That is much easier with cd_hash and cd_dev
> than with hash and dev.
>
> No, it is a good habit, these prefixes, even though it is no longer
> necessary because of
On Tue, May 22, 2001 at 11:08:16AM -0500, Oliver Xymoron wrote:
> > >+ struct list_headhash;
> > Why not name consistently with the struct block_device?
> > struct list_headcd_hash;
> Because foo_ is a throwback to the days when C compilers had a single
> namespac
On Tue, 22 May 2001, Oliver Xymoron wrote:
> > Not always. If the thing is used all over the tree, it'd better be
> > greppable. I hate the foo->de stuff - it's not localized and it's
> > impossible to grep for.
>
> I'd like to say the compiler will happily find it for you, but the
> kernel's
On Tue, 22 May 2001, Alexander Viro wrote:
> On Tue, 22 May 2001, Oliver Xymoron wrote:
>
> > Because foo_ is a throwback to the days when C compilers had a single
> > namespace for all structure elements, not a readability aid. If you need
> > foo_ to know what type of structure you're futzing w
On Tue, 22 May 2001, Oliver Xymoron wrote:
> Because foo_ is a throwback to the days when C compilers had a single
> namespace for all structure elements, not a readability aid. If you need
> foo_ to know what type of structure you're futzing with, you need to name
> your variables better.
Not
On Tue, 22 May 2001, Anton Altaparmakov wrote:
> Hello,
>
> At 15:18 22/05/01, Alexander Viro wrote:
> [snip cool stuff]
> >+struct char_device {
> >+ struct list_headhash;
> >+ atomic_tcount;
> >+ dev_t dev;
> >+ atomic_t
Hello,
At 15:18 22/05/01, Alexander Viro wrote:
[snip cool stuff]
>diff -urN S5-pre4/include/linux/fs.h S5-pre4-cdev/include/linux/fs.h
>--- S5-pre4/include/linux/fs.h Sat May 19 22:46:36 2001
>+++ S5-pre4-cdev/include/linux/fs.h Tue May 22 09:14:25 2001
>@@ -384,6 +384,14 @@
> int
Yes, I thought about it again, and you are right. Sorry for the noise.
Regards, Tommy
--- Mark Hahn <[EMAIL PROTECTED]> wrote:
> > + if ((flags & (SLAB_CTOR_VERIFY|SLAB_CTOR_CONSTRUCTOR)) ==
> > + SLAB_CTOR_CONSTRUCTOR)
> ...
> > + if ((flags & SLAB_CTOR_CONSTRUCTOR) == SLAB_CTOR_CONSTRUCTOR)
Hi Alexander!
If I'm not entirely mistaken, this:
+ if ((flags & (SLAB_CTOR_VERIFY|SLAB_CTOR_CONSTRUCTOR)) ==
+ SLAB_CTOR_CONSTRUCTOR)
+ {
+ memset(cdev, 0, sizeof(*cdev));
+ sema_init(&cdev->sem, 1);
+ }
+}
could be replaced with this:
+ if ((flags & SLAB_CTOR_CONSTRUCTOR) == SLAB_CTOR
53 matches
Mail list logo
