Re: [patch][rfc] rewrite ramdisk

2007-10-17 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-17 Thread Eric W. Biederman
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

Re: [patch][rfc] rewrite ramdisk

2007-10-17 Thread Nick Piggin
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 >

Re: [patch][rfc] rewrite ramdisk

2007-10-17 Thread Eric W. Biederman
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 >> >

Re: [patch][rfc] rewrite ramdisk

2007-10-17 Thread Eric W. Biederman
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

Re: [patch][rfc] rewrite ramdisk

2007-10-17 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-17 Thread Eric W. Biederman
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!

Re: [patch][rfc] rewrite ramdisk

2007-10-17 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Eric W. Biederman
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: >> >> > + /* >>

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Eric W. Biederman
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.

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Theodore Tso
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Eric W. Biederman
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,

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Jan Engelhardt
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Jan Engelhardt
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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--- > >+

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Jan Engelhardt
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? -^ >+

[patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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

[patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Jan Engelhardt
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Jan Engelhardt
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.

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Jan Engelhardt
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Eric W. Biederman
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,

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Theodore Tso
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Eric W. Biederman
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Eric W. Biederman
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

Re: [patch][rfc] rewrite ramdisk

2007-10-16 Thread Nick Piggin
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