On Thu, 2 Aug 2007, Miklos Szeredi wrote:
> > If you define a new flag like GFP_ZERO_ATOMIC and GFP_ZERO_KERNEL you
> > could do
> >
> > kalloc(struct, GFP_ZERO_KERNEL)
> >
> > instead of adding new variants?
>
> I don't really like this, introducing new gfp flags just makes
> grepping
> > The linux kernel doesn't have a type safe object allocator a-la new()
> > in C++ or g_new() in glib.
> >
> > Introduce two helpers for this purpose:
> >
> >alloc_struct(type, gfp_flags);
> >
> >zalloc_struct(type, gfp_flags);
>
> whimper.
>
> On a practical note, I'm still buried
On Thu, 02 Aug 2007 13:31:56 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> The linux kernel doesn't have a type safe object allocator a-la new()
> in C++ or g_new() in glib.
>
> Introduce two helpers for this purpose:
>
>alloc_struct(type, gfp_flags);
>
>zalloc_struct(type,
On Thu, 2 Aug 2007, Miklos Szeredi wrote:
>
> The number of variations can be reduced to just zeroing/nonzeroing, by
> making the array length mandatory. That's what glib does in g_new().
Quite frankly, you don't need the zeroing. That's what __GFP_ZERO does in
the flags.
That said, I'm not
On Aug 2 2007 16:06, Bernd Petrovitsch wrote:
>> thrice in some cases like alloc_struct(struct task_struct, GFP_KERNEL)
>
>Save the explicit "struct" and put it into the macro (and force people
>to not use typedefs).
>
>#define alloc_struct(type, flags) ((type *)kmalloc(sizeof(struct type),
On Thu, 2007-08-02 at 15:47 +0200, Peter Zijlstra wrote:
> On Thu, 2007-08-02 at 16:04 +0400, Alexey Dobriyan wrote:
> > On 8/2/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > The linux kernel doesn't have a type safe object allocator a-la new()
> > > in C++ or g_new() in glib.
> > >
> > >
> >> On Aug 2 2007 16:04, Alexey Dobriyan wrote:
> >> >On 8/2/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >> >> fooptr = kmalloc(sizeof(struct foo), ...);
> >> >
> >> >Key word is "traditional". Good traditional form which even half-competent
> >> >C programmers immediately parse in retina.
On Thu, 2007-08-02 at 16:04 +0400, Alexey Dobriyan wrote:
> On 8/2/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > The linux kernel doesn't have a type safe object allocator a-la new()
> > in C++ or g_new() in glib.
> >
> > Introduce two helpers for this purpose:
> >
> >alloc_struct(type,
On Aug 2 2007 15:06, Miklos Szeredi wrote:
>> On Aug 2 2007 16:04, Alexey Dobriyan wrote:
>> >On 8/2/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>> >> fooptr = kmalloc(sizeof(struct foo), ...);
>> >
>> >Key word is "traditional". Good traditional form which even half-competent
>> >C
> On Aug 2 2007 16:04, Alexey Dobriyan wrote:
> >On 8/2/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >> fooptr = kmalloc(sizeof(struct foo), ...);
> >
> >Key word is "traditional". Good traditional form which even half-competent
> >C programmers immediately parse in retina.
>
> And being
> Folks, this is serious. _We_ might be used to having in effect a C dialect
> with extensions implemented by preprocessor. That's fine, but for a fresh
> reader it becomes a problem; sure, they can dig in include/linux/*.h and
> to some extent they clearly have to. However, it doesn't come for
On Aug 2 2007 16:04, Alexey Dobriyan wrote:
>On 8/2/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>> fooptr = kmalloc(sizeof(struct foo), ...);
>
>Key word is "traditional". Good traditional form which even half-competent
>C programmers immediately parse in retina.
And being aware of the
On Thu, Aug 02, 2007 at 09:27:57AM +0200, Miklos Szeredi wrote:
> > Quite frankly, I suspect you would be better off just instrumenting
> > "sparse" instead, and matching up the size of the allocation with the type
> > it gets assigned to.
>
> But that just can't be done, because kmalloc()
On 8/2/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> The linux kernel doesn't have a type safe object allocator a-la new()
> in C++ or g_new() in glib.
>
> Introduce two helpers for this purpose:
>
>alloc_struct(type, gfp_flags);
>
>zalloc_struct(type, gfp_flags);
ick.
> These macros
From: Miklos Szeredi <[EMAIL PROTECTED]>
The linux kernel doesn't have a type safe object allocator a-la new()
in C++ or g_new() in glib.
Introduce two helpers for this purpose:
alloc_struct(type, gfp_flags);
zalloc_struct(type, gfp_flags);
These macros take a type name (usually a
> >
> > +/**
> > + * k_new - allocate given type object
> > + * @type: the type of the object to allocate
> > + * @flags: the type of memory to allocate.
> > + */
> > +#define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags))
>
> What others already said, plus:
>
> kmalloc()'ing
> > I wonder why we don't have type safe object allocators a-la new() in
> > C++ or g_new() in glib?
> >
> > fooptr = k_new(struct foo, GFP_KERNEL);
> >
> > is nicer and more descriptive than
> >
> > fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
> >
> > and more safe than
> >
> >
> >
> > I wonder why we don't have type safe object allocators a-la new() in
> > C++ or g_new() in glib?
> >
> > fooptr = k_new(struct foo, GFP_KERNEL);
>
> I would object to this if only because of the horrible name.
>
> C++ is not a good language to take ideas from, and "new()" was not it's
Hi Miklos,
On Wed, 1 Aug 2007, Miklos Szeredi wrote:
> I wonder why we don't have type safe object allocators a-la new() in
> C++ or g_new() in glib?
>
> fooptr = k_new(struct foo, GFP_KERNEL);
>
> is nicer and more descriptive than
>
> fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
>
>
Hi Miklos,
On Wed, 1 Aug 2007, Miklos Szeredi wrote:
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
is nicer and more descriptive than
fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
and more
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
I would object to this if only because of the horrible name.
C++ is not a good language to take ideas from, and new() was not it's
best feature
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
is nicer and more descriptive than
fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
and more safe than
fooptr =
+/**
+ * k_new - allocate given type object
+ * @type: the type of the object to allocate
+ * @flags: the type of memory to allocate.
+ */
+#define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags))
What others already said, plus:
kmalloc()'ing sizeof(struct foo) is
From: Miklos Szeredi [EMAIL PROTECTED]
The linux kernel doesn't have a type safe object allocator a-la new()
in C++ or g_new() in glib.
Introduce two helpers for this purpose:
alloc_struct(type, gfp_flags);
zalloc_struct(type, gfp_flags);
These macros take a type name (usually a 'struct
On 8/2/07, Miklos Szeredi [EMAIL PROTECTED] wrote:
The linux kernel doesn't have a type safe object allocator a-la new()
in C++ or g_new() in glib.
Introduce two helpers for this purpose:
alloc_struct(type, gfp_flags);
zalloc_struct(type, gfp_flags);
ick.
These macros take a type
On Aug 2 2007 16:04, Alexey Dobriyan wrote:
On 8/2/07, Miklos Szeredi [EMAIL PROTECTED] wrote:
fooptr = kmalloc(sizeof(struct foo), ...);
Key word is traditional. Good traditional form which even half-competent
C programmers immediately parse in retina.
And being aware of the potential
On Thu, Aug 02, 2007 at 09:27:57AM +0200, Miklos Szeredi wrote:
Quite frankly, I suspect you would be better off just instrumenting
sparse instead, and matching up the size of the allocation with the type
it gets assigned to.
But that just can't be done, because kmalloc() doesn't tell
On Aug 2 2007 16:04, Alexey Dobriyan wrote:
On 8/2/07, Miklos Szeredi [EMAIL PROTECTED] wrote:
fooptr = kmalloc(sizeof(struct foo), ...);
Key word is traditional. Good traditional form which even half-competent
C programmers immediately parse in retina.
And being aware of the
On Aug 2 2007 15:06, Miklos Szeredi wrote:
On Aug 2 2007 16:04, Alexey Dobriyan wrote:
On 8/2/07, Miklos Szeredi [EMAIL PROTECTED] wrote:
fooptr = kmalloc(sizeof(struct foo), ...);
Key word is traditional. Good traditional form which even half-competent
C programmers immediately parse
Folks, this is serious. _We_ might be used to having in effect a C dialect
with extensions implemented by preprocessor. That's fine, but for a fresh
reader it becomes a problem; sure, they can dig in include/linux/*.h and
to some extent they clearly have to. However, it doesn't come for
On Aug 2 2007 16:04, Alexey Dobriyan wrote:
On 8/2/07, Miklos Szeredi [EMAIL PROTECTED] wrote:
fooptr = kmalloc(sizeof(struct foo), ...);
Key word is traditional. Good traditional form which even half-competent
C programmers immediately parse in retina.
And being aware of the
On Thu, 2007-08-02 at 16:04 +0400, Alexey Dobriyan wrote:
On 8/2/07, Miklos Szeredi [EMAIL PROTECTED] wrote:
The linux kernel doesn't have a type safe object allocator a-la new()
in C++ or g_new() in glib.
Introduce two helpers for this purpose:
alloc_struct(type, gfp_flags);
On Aug 2 2007 16:06, Bernd Petrovitsch wrote:
thrice in some cases like alloc_struct(struct task_struct, GFP_KERNEL)
Save the explicit struct and put it into the macro (and force people
to not use typedefs).
#define alloc_struct(type, flags) ((type *)kmalloc(sizeof(struct type),
(flags)))
On Thu, 2007-08-02 at 15:47 +0200, Peter Zijlstra wrote:
On Thu, 2007-08-02 at 16:04 +0400, Alexey Dobriyan wrote:
On 8/2/07, Miklos Szeredi [EMAIL PROTECTED] wrote:
The linux kernel doesn't have a type safe object allocator a-la new()
in C++ or g_new() in glib.
Introduce two
On Thu, 2 Aug 2007, Miklos Szeredi wrote:
The number of variations can be reduced to just zeroing/nonzeroing, by
making the array length mandatory. That's what glib does in g_new().
Quite frankly, you don't need the zeroing. That's what __GFP_ZERO does in
the flags.
That said, I'm not at
On Thu, 02 Aug 2007 13:31:56 +0200
Miklos Szeredi [EMAIL PROTECTED] wrote:
The linux kernel doesn't have a type safe object allocator a-la new()
in C++ or g_new() in glib.
Introduce two helpers for this purpose:
alloc_struct(type, gfp_flags);
zalloc_struct(type, gfp_flags);
The linux kernel doesn't have a type safe object allocator a-la new()
in C++ or g_new() in glib.
Introduce two helpers for this purpose:
alloc_struct(type, gfp_flags);
zalloc_struct(type, gfp_flags);
whimper.
On a practical note, I'm still buried in
On Thu, 2 Aug 2007, Miklos Szeredi wrote:
If you define a new flag like GFP_ZERO_ATOMIC and GFP_ZERO_KERNEL you
could do
kalloc(struct, GFP_ZERO_KERNEL)
instead of adding new variants?
I don't really like this, introducing new gfp flags just makes
grepping harder.
The
On Wed, 1 Aug 2007, Miklos Szeredi wrote:
> I wonder why we don't have type safe object allocators a-la new() in
> C++ or g_new() in glib?
>
> fooptr = k_new(struct foo, GFP_KERNEL);
>
> is nicer and more descriptive than
>
> fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
>
> and more
On Wed, 1 Aug 2007, Miklos Szeredi wrote:
>
> I wonder why we don't have type safe object allocators a-la new() in
> C++ or g_new() in glib?
>
> fooptr = k_new(struct foo, GFP_KERNEL);
I would object to this if only because of the horrible name.
C++ is not a good language to take ideas
> >> >
> >> > #define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags))
> >>
> >> The cast doesn't make it more safe in any way
> >
> >I does, since a warning will be issued, if the type of the assigned
> >pointer doesn't match the requested allocation.
> >
> >And yes, warnings are
On Aug 1 2007 12:45, Miklos Szeredi wrote:
>> >
>> > #define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags))
>>
>> The cast doesn't make it more safe in any way
>
>I does, since a warning will be issued, if the type of the assigned
>pointer doesn't match the requested allocation.
>
> >
> > #define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags))
>
> The cast doesn't make it more safe in any way
I does, since a warning will be issued, if the type of the assigned
pointer doesn't match the requested allocation.
And yes, warnings are _very_ useful in C for
Miklos Szeredi <[EMAIL PROTECTED]> writes:
>
> #define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags))
The cast doesn't make it more safe in any way
(at least as long as you don't care about portability to C++;
the kernel doesn't)
-Andi
-
To unsubscribe from this list: send the line
> > I wonder why we don't have type safe object allocators a-la new() in
> > C++ or g_new() in glib?
> >
> > fooptr = k_new(struct foo, GFP_KERNEL);
> >
> > is nicer and more descriptive than
> >
> > fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
> >
> > and more safe than
> >
> >
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> I wonder why we don't have type safe object allocators a-la new() in
> C++ or g_new() in glib?
>
> fooptr = k_new(struct foo, GFP_KERNEL);
>
> is nicer and more descriptive than
>
> fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
>
> and more
> > I wonder why we don't have type safe object allocators a-la new() in
> > C++ or g_new() in glib?
> >
> > fooptr = k_new(struct foo, GFP_KERNEL);
> >
> > is nicer and more descriptive than
> >
> > fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
> >...
>
> But it's much more likely to
On Wed, Aug 01, 2007 at 11:06:46AM +0200, Miklos Szeredi wrote:
> I wonder why we don't have type safe object allocators a-la new() in
> C++ or g_new() in glib?
>
> fooptr = k_new(struct foo, GFP_KERNEL);
>
> is nicer and more descriptive than
>
> fooptr = kmalloc(sizeof(*fooptr),
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
is nicer and more descriptive than
fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
and more safe than
fooptr = kmalloc(sizeof(struct foo), GFP_KERNEL);
Miklos Szeredi [EMAIL PROTECTED] writes:
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
is nicer and more descriptive than
fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
and more safe than
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
is nicer and more descriptive than
fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
...
But it's much more likely to break when someone
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
is nicer and more descriptive than
fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
and more safe than
fooptr = kmalloc(sizeof(struct foo), GFP_KERNEL);
On Wed, Aug 01, 2007 at 11:06:46AM +0200, Miklos Szeredi wrote:
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
is nicer and more descriptive than
fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
...
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
is nicer and more descriptive than
fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
and more safe than
fooptr =
#define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags))
The cast doesn't make it more safe in any way
I does, since a warning will be issued, if the type of the assigned
pointer doesn't match the requested allocation.
And yes, warnings are _very_ useful in C for enforcing type
Miklos Szeredi [EMAIL PROTECTED] writes:
#define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags))
The cast doesn't make it more safe in any way
(at least as long as you don't care about portability to C++;
the kernel doesn't)
-Andi
-
To unsubscribe from this list: send the line
On Aug 1 2007 12:45, Miklos Szeredi wrote:
#define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags))
The cast doesn't make it more safe in any way
I does, since a warning will be issued, if the type of the assigned
pointer doesn't match the requested allocation.
And yes,
#define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags))
The cast doesn't make it more safe in any way
I does, since a warning will be issued, if the type of the assigned
pointer doesn't match the requested allocation.
And yes, warnings are _very_ useful in C for
On Wed, 1 Aug 2007, Miklos Szeredi wrote:
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
I would object to this if only because of the horrible name.
C++ is not a good language to take ideas from, and
On Wed, 1 Aug 2007, Miklos Szeredi wrote:
I wonder why we don't have type safe object allocators a-la new() in
C++ or g_new() in glib?
fooptr = k_new(struct foo, GFP_KERNEL);
is nicer and more descriptive than
fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL);
and more safe than
60 matches
Mail list logo
