[Bug 1001656] FreeBSD: add AF_PACKET socket familiy

[bugzilla-daemon@bugs.ecos.sourceware.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 15057 bytes --]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001656

Juergen Lambrecht <J.Lambrecht@televic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |J.Lambrecht@televic.com

--- Comment #5 from Juergen Lambrecht <J.Lambrecht@televic.com> ---
(In reply to comment #2)
> Regarding AF_PACKET:
> 
> The protocol AF_PACKET will only be available when you call
> cyg_use_af_packet() somewhere in your application.
> 
> If this function is not called the af_packet.c is not linked and
> the binary will not become any larger due to this enhancement.
> 
> After this is done, these sockets can be used exactly as described here:
> 
> man 7 packet

Hi Bernd,

Because I am porting the busybox dhcp server to eCos, I am using your raw
packet patch.
When I do 'man 7 packet' on my linux, I get a slightly different definition of
'struct sockaddr_ll' (as also used by busybox): I have 'int sll_ifindex;'
instead of 'u_short sll_index;' and 'unsigned char sll_addr[8];' instead of
'u_char sll_addr[22];'.
I guess the naming difference is because your code is based on the freeBSD, and
the busybox is based on Linux.
But why 22 bytes for the address ('ssl_addr'), you only use 6B of it
(EHTER_ADDR_LEN)?

Kind regards,
Jürgen

-- 
You are receiving this mail because:
You are the assignee for the bug.
>From ecos-bugs-return-10498-listarch-ecos-bugs=sources.redhat.com@sourceware.org Mon Jul 15 12:58:14 2013
Return-Path: <ecos-bugs-return-10498-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 29094 invoked by alias); 15 Jul 2013 12:58:13 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 29058 invoked by uid 89); 15 Jul 2013 12:58:13 -0000
X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RDNS_NONE,SPF_PASS autolearn=ham version=3.3.1
Received: from Unknown (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 15 Jul 2013 12:58:12 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 1BE714680012; Mon, 15 Jul 2013 13:58:04 +0100 (BST)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001656] FreeBSD: add AF_PACKET socket familiy
Date: Mon, 15 Jul 2013 12:58:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Patches and contributions
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: bernd.edlinger@hotmail.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: high
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001656-777-5Ny41Zvhu3@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001656-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001656-777@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013/txt/msg00529.txt.bz2
Content-length: 2151

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001656

--- Comment #6 from Bernd Edlinger <bernd.edlinger@hotmail.de> ---
(In reply to comment #5)
Hi Jürgen,

> Because I am porting the busybox dhcp server to eCos, I am using your raw
> packet patch.
> When I do 'man 7 packet' on my linux, I get a slightly different definition
> of 'struct sockaddr_ll' (as also used by busybox): I have 'int sll_ifindex;'
> instead of 'u_short sll_index;' and 'unsigned char sll_addr[8];' instead of
> 'u_char sll_addr[22];'.
> I guess the naming difference is because your code is based on the freeBSD,
> and the busybox is based on Linux.
> But why 22 bytes for the address ('ssl_addr'), you only use 6B of it
> (EHTER_ADDR_LEN)?

good questions...

1. actually the name should be sll_ifindex. I somehow missed that typo.

2. the data type that is used by the bsd stack to index the interfaces
   is u_short, therefore I thought it would be better to use that instead.
   Same for the SIOCGIFINDEX ioctl, which uses only u_short.

3. in linux sizeof (struct sockaddr_ll) = 20 which is larger than
   sizeof(struct sockaddr) = 16.
   But on eCos the sockaddr is 32 bytes. Therefore the sockaddr_ll
   must be at least 32 bytes. Therefore I enlarged the sll_addr to 22.

Note: All socket addressses should be exactly 32 bytes in eCos,
because of this code in ./io/fileio/current/src/socket.cxx:

__externC int   bind (int s, const struct sockaddr *sa, unsigned int len)
{
...
    struct sockaddr sa2 = *sa;



regading 1, I will change the name.

regarding 2, I could change the type to int, and cast it
to u_short later, but only if that improves protability.

Is it your impression that this change would improve the
portability of the busybox dhcp server?

regarding 3, the sizeof sll_addr should be irrelevant to
the application as only 6 bytes are really used.

Does the existion code use the size of the sll_addr array
for anything? Does it break unless this array is exactly 8 bytes?


Regards
Bernd.

-- 
You are receiving this mail because:
You are the assignee for the bug.
>From ecos-bugs-return-10499-listarch-ecos-bugs=sources.redhat.com@sourceware.org Mon Jul 15 15:39:55 2013
Return-Path: <ecos-bugs-return-10499-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 8501 invoked by alias); 15 Jul 2013 15:39:55 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 8486 invoked by uid 89); 15 Jul 2013 15:39:55 -0000
X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RDNS_NONE,SPF_PASS autolearn=ham version=3.3.1
Received: from Unknown (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 15 Jul 2013 15:39:54 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 43B484680014; Mon, 15 Jul 2013 16:39:46 +0100 (BST)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001656] FreeBSD: add AF_PACKET socket familiy
Date: Mon, 15 Jul 2013 15:39:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Patches and contributions
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: J.Lambrecht@televic.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: high
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001656-777-sWxYGvQs76@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001656-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001656-777@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013/txt/msg00530.txt.bz2
Content-length: 2506

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001656

--- Comment #7 from Juergen Lambrecht <J.Lambrecht@televic.com> ---
(In reply to comment #6)
> (In reply to comment #5)
> Hi Jürgen,
> 
> > Because I am porting the busybox dhcp server to eCos, I am using your raw
> > packet patch.
> > When I do 'man 7 packet' on my linux, I get a slightly different definition
> > of 'struct sockaddr_ll' (as also used by busybox): I have 'int sll_ifindex;'
> > instead of 'u_short sll_index;' and 'unsigned char sll_addr[8];' instead of
> > 'u_char sll_addr[22];'.
> > I guess the naming difference is because your code is based on the freeBSD,
> > and the busybox is based on Linux.
> > But why 22 bytes for the address ('ssl_addr'), you only use 6B of it
> > (EHTER_ADDR_LEN)?
> 
> good questions...
> 
> 1. actually the name should be sll_ifindex. I somehow missed that typo.
> 
> 2. the data type that is used by the bsd stack to index the interfaces
>    is u_short, therefore I thought it would be better to use that instead.
>    Same for the SIOCGIFINDEX ioctl, which uses only u_short.
> 
> 3. in linux sizeof (struct sockaddr_ll) = 20 which is larger than
>    sizeof(struct sockaddr) = 16.
>    But on eCos the sockaddr is 32 bytes. Therefore the sockaddr_ll
>    must be at least 32 bytes. Therefore I enlarged the sll_addr to 22.
> 
> Note: All socket addressses should be exactly 32 bytes in eCos,
> because of this code in ./io/fileio/current/src/socket.cxx:
> 
> __externC int   bind (int s, const struct sockaddr *sa, unsigned int len)
> {
> ...
>     struct sockaddr sa2 = *sa;
> 
> 
> 
> regading 1, I will change the name.
OK, I did the same
> 
> regarding 2, I could change the type to int, and cast it
> to u_short later, but only if that improves protability.
> 
> Is it your impression that this change would improve the
> portability of the busybox dhcp server?
No, it's OK. The code compiled without warnings so far.
> 
> regarding 3, the sizeof sll_addr should be irrelevant to
> the application as only 6 bytes are really used.
> 
> Does the existion code use the size of the sll_addr array
> for anything? Does it break unless this array is exactly 8 bytes?
No. Busybox code also only uses 6B instead of the 8 they have.
So it is OK.

Thanks for your reply,
Jürgen
> 
> 
> Regards
> Bernd.

-- 
You are receiving this mail because:
You are the assignee for the bug.
>From ecos-bugs-return-10500-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Jul 17 20:12:24 2013
Return-Path: <ecos-bugs-return-10500-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 24839 invoked by alias); 17 Jul 2013 20:12:24 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 24829 invoked by uid 89); 17 Jul 2013 20:12:23 -0000
X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RDNS_NONE,SPF_PASS autolearn=no version=3.3.1
Received: from Unknown (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 17 Jul 2013 20:12:23 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 2D221468001A; Wed, 17 Jul 2013 21:12:15 +0100 (BST)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001881] New: Allow FIS cmd to handle multiple flash devices
 with different block alignments
Date: Wed, 17 Jul 2013 20:12:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Patches and contributions
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: sarcastic.mannequin@gmail.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform
 op_sys bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-1001881-777@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013/txt/msg00531.txt.bz2
Content-length: 1424

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001881

            Bug ID: 1001881
           Summary: Allow FIS cmd to handle multiple flash devices with
                    different block alignments
           Product: eCos
           Version: unknown
            Target: All
  Architecture/Host Other
                OS:
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Patches and contributions
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: sarcastic.mannequin@gmail.com
                CC: ecos-patches@ecos.sourceware.org

Created attachment 2336
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id#36&actioníit
Allow FIS cmd to handle multiple flash devices with different block alignments

This patch allows Redboot FIS command to manage multiple flash devices even
when the flash devices have different block sizes/alignments.

Note this is not about different block sizes in a single flash device, this is
about different block sizes in multiple flash devices.

Noticed this problem with Redboot on a board that has embedded flash in SoC and
also a SPI dataflash device. Most FIS operations were failing because it was
using alignment from embedded flash even on dataflash device.

--
You are receiving this mail because:
You are the assignee for the bug.