Roman Zippel writes:
> Hi,
>
> On Fri, 28 Jan 2005, Tom Zanussi wrote:
>
> > +static inline int rchan_create_file(const char *chanpath,
> > + struct dentry **dentry,
> > + struct rchan_buf *data)
> > +{
> > + int err;
> > + con
Hi,
On Fri, 28 Jan 2005, Tom Zanussi wrote:
> +static inline int rchan_create_file(const char *chanpath,
> + struct dentry **dentry,
> + struct rchan_buf *data)
> +{
> + int err;
> + const char * fname;
> + struct dentry
Greg KH wrote:
> When relayfs is built into the kernel, those symbols are then global to
> the whole static kernel.
>
> Please be nice and rename them.
My pleasure :)
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opers
On Mon, Jan 31, 2005 at 05:10:27PM -0500, Karim Yaghmour wrote:
>
> Greg KH wrote:
> > On Fri, Jan 28, 2005 at 01:38:22PM -0600, Tom Zanussi wrote:
> >
> >>+extern void * alloc_rchan_buf(unsigned long size,
> >>+ struct page ***page_array,
> >>+ int
Greg KH wrote:
> On Fri, Jan 28, 2005 at 01:38:22PM -0600, Tom Zanussi wrote:
>
>>+extern void * alloc_rchan_buf(unsigned long size,
>>+ struct page ***page_array,
>>+ int *page_count);
>>+extern void free_rchan_buf(void *buf,
>>+
Tom Zanussi wrote:
> I don't think they need to be mutually exclusive - we could keep
> relay_reserve(), but the relay_write() that's currently built on top
> of relay_reserve() would use the putc code instead. It's complicating
> the API a bit, but if it makes everyone happy...
Actually I think
Karim Yaghmour writes:
>
> Tom Zanussi wrote:
> > OK, makes sense to me - I'll get rid of relay_reserve and replace it
> > with the simple putc write and variant.
>
> Please don't do that. Instead, bring back the ad-hoc mode code, that's
> what is was for anyway.
>
I don't think they ne
Tom Zanussi wrote:
> OK, makes sense to me - I'll get rid of relay_reserve and replace it
> with the simple putc write and variant.
Please don't do that. Instead, bring back the ad-hoc mode code, that's
what is was for anyway.
> You could just create and log into a separate relayfs channel, if y
Andi Kleen wrote:
> It's doing a complicated function call which does who knows what in
> the logging fast path (I stopped reading after some point)
> It definitely is not putc !
I was anticipating some people would have this requirement, and this
is why I introduced the ad-hoc mode. Roman aske
Andi Kleen writes:
> On Sat, Jan 29, 2005 at 10:58:22PM -0600, Tom Zanussi wrote:
> > > The logging fast path seems still a bit slow to me. I would like
> > > to have a logging macro that is not much worse than a stdio putc,
> > > basically something like
> > >
> > > get_cpu()
On Sat, Jan 29, 2005 at 10:58:22PM -0600, Tom Zanussi wrote:
> > The logging fast path seems still a bit slow to me. I would like
> > to have a logging macro that is not much worse than a stdio putc,
> > basically something like
> >
> > get_cpu();
> > if (buffer space > N
Greg KH writes:
> On Fri, Jan 28, 2005 at 01:38:22PM -0600, Tom Zanussi wrote:
> > +extern void * alloc_rchan_buf(unsigned long size,
> > +struct page ***page_array,
> > +int *page_count);
> > +extern void free_rchan_buf(void *buf,
> > +
Andi Kleen writes:
> Tom Zanussi <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > This patch is the result of the latest round of liposuction on relayfs
> > - the patch size is now 44K, down from 110K and the 200K before that.
> > I'm posting it as a patch against 2.6.10 rather than -mm in ord
On Fri, Jan 28, 2005 at 01:38:22PM -0600, Tom Zanussi wrote:
> +extern void * alloc_rchan_buf(unsigned long size,
> + struct page ***page_array,
> + int *page_count);
> +extern void free_rchan_buf(void *buf,
> +struct page
Tom Zanussi <[EMAIL PROTECTED]> writes:
> Hi,
>
> This patch is the result of the latest round of liposuction on relayfs
> - the patch size is now 44K, down from 110K and the 200K before that.
> I'm posting it as a patch against 2.6.10 rather than -mm in order to
> make it easier to review, but wi
Tom Zanussi <[EMAIL PROTECTED]> wrote:
>
> This patch is the result of the latest round of liposuction on relayfs
> - the patch size is now 44K, down from 110K and the 200K before that.
> I'm posting it as a patch against 2.6.10 rather than -mm in order to
> make it easier to review, but will cr
Tom Zanussi wrote:
> diff -urpN -X dontdiff linux-2.6.10/fs/Kconfig linux-2.6.10-cur/fs/Kconfig
...
> + This file system is also available as a module ( = code which can be
> + inserted in and removed from the running kernel whenever you want).
> + The module is called relayfs.
Hi,
This patch is the result of the latest round of liposuction on relayfs
- the patch size is now 44K, down from 110K and the 200K before that.
I'm posting it as a patch against 2.6.10 rather than -mm in order to
make it easier to review, but will create one for -mm once the changes
have settled
18 matches
Mail list logo
