On Thursday 18 October 2007 04:45, Eric W. Biederman wrote:
> At this point my concern is what makes a clean code change in the
> kernel. Because user space can currently play with buffer_heads
> by way of the block device and cause lots of havoc (see the recent
Well if userspace is writing to
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Wednesday 17 October 2007 20:30, Eric W. Biederman wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>> > On Tuesday 16 October 2007 18:08, Nick Piggin wrote:
>> >> On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote:
>> >> > > What magic
On Wednesday 17 October 2007 20:30, Eric W. Biederman wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > On Tuesday 16 October 2007 18:08, Nick Piggin wrote:
> >> On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote:
> >> > > What magic restrictions on page allocations? Actually we have
>
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Tuesday 16 October 2007 18:08, Nick Piggin wrote:
>> On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote:
>
>> > > What magic restrictions on page allocations? Actually we have
>> > > fewer restrictions on page allocations because we can use
>> >
Nick Piggin [EMAIL PROTECTED] writes:
On Wednesday 17 October 2007 20:30, Eric W. Biederman wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Tuesday 16 October 2007 18:08, Nick Piggin wrote:
On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote:
What magic restrictions on page
On Thursday 18 October 2007 04:45, Eric W. Biederman wrote:
At this point my concern is what makes a clean code change in the
kernel. Because user space can currently play with buffer_heads
by way of the block device and cause lots of havoc (see the recent
Well if userspace is writing to the
Nick Piggin [EMAIL PROTECTED] writes:
On Tuesday 16 October 2007 18:08, Nick Piggin wrote:
On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote:
What magic restrictions on page allocations? Actually we have
fewer restrictions on page allocations because we can use
highmem!
On Wednesday 17 October 2007 20:30, Eric W. Biederman wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Tuesday 16 October 2007 18:08, Nick Piggin wrote:
On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote:
What magic restrictions on page allocations? Actually we have
fewer
On Wednesday 17 October 2007 11:13, Eric W. Biederman wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > We have 2 problems. First is that, for testing/consistency, we
> > don't want BLKFLSBUF to throw out the data. Maybe hardly anything
> > uses BLKFLSBUF now, so it could be just a minor
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Wednesday 17 October 2007 09:48, Eric W. Biederman wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>> > On Wednesday 17 October 2007 07:28, Theodore Tso wrote:
>> >> On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote:
>> >> > + /*
>>
On Wednesday 17 October 2007 09:48, Eric W. Biederman wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > On Wednesday 17 October 2007 07:28, Theodore Tso wrote:
> >> On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote:
> >> > +/*
> >> > + * ram device BLKFLSBUF has
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Wednesday 17 October 2007 07:28, Theodore Tso wrote:
>> On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote:
>> > + /*
>> > + * ram device BLKFLSBUF has special semantics, we want to actually
>> > + * release and destroy the ramdisk data.
On Wednesday 17 October 2007 07:28, Theodore Tso wrote:
> On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote:
> > + /*
> > +* ram device BLKFLSBUF has special semantics, we want to actually
> > +* release and destroy the ramdisk data.
> > +*/
>
> We won't be able to fix
On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote:
> + /*
> + * ram device BLKFLSBUF has special semantics, we want to actually
> + * release and destroy the ramdisk data.
> + */
We won't be able to fix completely this for a while time, but the fact
that BLKFLSBUF has
Well on that same tune. But with a slightly different implementation.
It compiles but I need to head to bed so I haven't had a chance
to test it yet.
Nick it is very similar to yours with the big difference being that
I embedded a struct address_space instead of rolled rerolled it by
hand,
On Oct 16 2007 18:26, Nick Piggin wrote:
>> >> It also does not seem needed, since it did not exist before.
>> >> It should go, you can set the variable with brd.rd_nr=XXX (same
>> >> goes for ramdisk_size).
>> >
>> >But only if it's a module?
>>
>> Attributes always work. Try
On Tuesday 16 October 2007 18:17, Jan Engelhardt wrote:
> On Oct 16 2007 18:07, Nick Piggin wrote:
> >Changed. But it will hopefully just completely replace rd.c,
> >so I will probably just rename it to rd.c at some point (and
> >change .config options to stay compatible). Unless someone
> >sees a
On Oct 16 2007 18:07, Nick Piggin wrote:
>Changed. But it will hopefully just completely replace rd.c,
>so I will probably just rename it to rd.c at some point (and
>change .config options to stay compatible). Unless someone
>sees a problem with that?
I do not see a problem with keeping brd
On Tuesday 16 October 2007 17:52, Jan Engelhardt wrote:
> On Oct 16 2007 17:47, Nick Piggin wrote:
> >Here's a quick first hack...
>
> Inline patches preferred ;-)
Thanks for reviewing it anyway ;)
> >+config BLK_DEV_BRD
> >+tristate "RAM block device support"
> >+---help---
> >+
On Oct 16 2007 17:47, Nick Piggin wrote:
>
>Here's a quick first hack...
Inline patches preferred ;-)
>+config BLK_DEV_BRD
>+ tristate "RAM block device support"
>+ ---help---
>+This is a new based block driver that replaces BLK_DEV_RAM.
based on what? -^
>+
On Tuesday 16 October 2007 18:08, Nick Piggin wrote:
> On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote:
> > > What magic restrictions on page allocations? Actually we have
> > > fewer restrictions on page allocations because we can use
> > > highmem!
> >
> > With the proposed rewrite
On Tuesday 16 October 2007 18:08, Nick Piggin wrote:
On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote:
What magic restrictions on page allocations? Actually we have
fewer restrictions on page allocations because we can use
highmem!
With the proposed rewrite yes.
Here's a
On Oct 16 2007 17:47, Nick Piggin wrote:
Here's a quick first hack...
Inline patches preferred ;-)
+config BLK_DEV_BRD
+ tristate RAM block device support
+ ---help---
+This is a new based block driver that replaces BLK_DEV_RAM.
based on what? -^
+To
On Tuesday 16 October 2007 17:52, Jan Engelhardt wrote:
On Oct 16 2007 17:47, Nick Piggin wrote:
Here's a quick first hack...
Inline patches preferred ;-)
Thanks for reviewing it anyway ;)
+config BLK_DEV_BRD
+tristate RAM block device support
+---help---
+ This is a new
On Oct 16 2007 18:07, Nick Piggin wrote:
Changed. But it will hopefully just completely replace rd.c,
so I will probably just rename it to rd.c at some point (and
change .config options to stay compatible). Unless someone
sees a problem with that?
I do not see a problem with keeping brd either.
On Tuesday 16 October 2007 18:17, Jan Engelhardt wrote:
On Oct 16 2007 18:07, Nick Piggin wrote:
Changed. But it will hopefully just completely replace rd.c,
so I will probably just rename it to rd.c at some point (and
change .config options to stay compatible). Unless someone
sees a problem
On Oct 16 2007 18:26, Nick Piggin wrote:
It also does not seem needed, since it did not exist before.
It should go, you can set the variable with brd.rd_nr=XXX (same
goes for ramdisk_size).
But only if it's a module?
Attributes always work. Try
Well on that same tune. But with a slightly different implementation.
It compiles but I need to head to bed so I haven't had a chance
to test it yet.
Nick it is very similar to yours with the big difference being that
I embedded a struct address_space instead of rolled rerolled it by
hand,
On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote:
+ /*
+ * ram device BLKFLSBUF has special semantics, we want to actually
+ * release and destroy the ramdisk data.
+ */
We won't be able to fix completely this for a while time, but the fact
that BLKFLSBUF has
On Wednesday 17 October 2007 07:28, Theodore Tso wrote:
On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote:
+ /*
+* ram device BLKFLSBUF has special semantics, we want to actually
+* release and destroy the ramdisk data.
+*/
We won't be able to fix completely this
Nick Piggin [EMAIL PROTECTED] writes:
On Wednesday 17 October 2007 07:28, Theodore Tso wrote:
On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote:
+ /*
+ * ram device BLKFLSBUF has special semantics, we want to actually
+ * release and destroy the ramdisk data.
+ */
We
On Wednesday 17 October 2007 09:48, Eric W. Biederman wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Wednesday 17 October 2007 07:28, Theodore Tso wrote:
On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote:
+/*
+ * ram device BLKFLSBUF has special semantics, we
Nick Piggin [EMAIL PROTECTED] writes:
On Wednesday 17 October 2007 09:48, Eric W. Biederman wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Wednesday 17 October 2007 07:28, Theodore Tso wrote:
On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote:
+ /*
+ * ram device
On Wednesday 17 October 2007 11:13, Eric W. Biederman wrote:
Nick Piggin [EMAIL PROTECTED] writes:
We have 2 problems. First is that, for testing/consistency, we
don't want BLKFLSBUF to throw out the data. Maybe hardly anything
uses BLKFLSBUF now, so it could be just a minor problem, but
34 matches
Mail list logo