From: Johan Rydberg <jrydberg@gnu.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Ethernet support [PATCH]
Date: Mon, 06 Aug 2007 22:07:45 +0200 [thread overview]
Message-ID: <878x8otoj2.fsf@gnu.org> (raw)
In-Reply-To: <87fy3194au.fsf@xs4all.nl> (Marco Gerards's message of "Thu, 02 Aug 2007 20:31:21 +0200")
[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]
Marco Gerards <mgerards@xs4all.nl> writes:
> If I do not get any comments within a week, I'll just commit the
> patch. >
I have a few more comments;
> +#include <grub/types.h>
> +#include <grub/err.h>
> +
> +enum grub_memstack_type
> + {
> + GRUB_MEMSTACK_TYPE_ETHERNET,
> + GRUB_MEMSTACK_TYPE_IPV4,
> + GRUB_MEMSTACK_TYPE_ARP,
> + GRUB_MEMSTACK_TYPE_UDP,
> + GRUB_MEMSTACK_TYPE_DATA /* XXX */
> + };
> +typedef enum grub_memstack_type grub_memstack_type_t;
I do not see why this is needed at all? The data should be opaque.
> +grub_memstack_t grub_memstack_new (void);
> +
> +void grub_memstack_free (grub_memstack_t stack);
> +
> +void *grub_memstack_push (grub_memstack_t stack,
> + grub_memstack_type_t type,
> + grub_size_t size);
> +
> +void *grub_memstack_bottom (grub_memstack_t stack,
> + grub_memstack_type_t type,
> + grub_size_t size);
> +
> +void *grub_memstack_pop (grub_memstack_t stack, grub_size_t *size);
> +
> +grub_err_t grub_memstack_popall (grub_memstack_t stack,
> + char *buf, grub_size_t *size);
> +
The network component in a operating system is often seen as a stack,
because packets travel up and down through a logical stack of
functionality layers. That doesn't say that the data that is passed
is really a stack. BSD uses a data structure called "mbufs", which
really just is a linked list of small data chunks. There are
operations to append, prepend and gather data from the "mbuf".
I suggest to remove the word "stack" from our data structure, and
replace it with something more generic; "buf" maybe?
And since it is really a linked list, _push should become prepend, and
_bottom append, respectively.
Also, I do not think that the read operation should be destructive.
Maybe a _read function is in order?
If we do this, we have a shot at adding a data structure that could be
used in other places than just our small network stack.
~j
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2007-08-06 19:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-02 18:31 Ethernet support [PATCH] Marco Gerards
2007-08-06 20:07 ` Johan Rydberg [this message]
2007-08-06 20:08 ` Johan Rydberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878x8otoj2.fsf@gnu.org \
--to=jrydberg@gnu.org \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.