Custom Search
|
Date: December 31, 2006
From: Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx>
In-reply-to:
<20061231.124531.125895122.davem@xxxxxxxxxxxxx>
References:
<459714A6.4000406@xxxxxxxxxxxxx> <Pine.LNX.4.61.0612311350060.32449@xxxxxxxxxxxxxxx> <20061231.124531.125895122.davem@xxxxxxxxxxxxx>
On Dec 31 2006 12:45, David Miller wrote:
>From: Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx>
>
>> BUT, the eeprom utility may be used to modify values, and if used, I
>> would like to see ofwfs show the updated value. openpromfs does it
>> today:
>>
>> 15:09 ares:/proc/openprom/options # cat oem-banner?
>> false
>> 15:09 ares:/proc/openprom/options # eeprom 'oem-banner?=true'
>> 15:09 ares:/proc/openprom/options # cat oem-banner?
>> true
>>
>> (BTW, why does not openpromfs have it rw?)
>
>It used to be able to :-)
>
>When I changed sparc/sparc64 over to an in-memory copy of the
>OFW tree, I wasn't able to retain writable property support
>in openpromfs. It just needs to be implemented and I never
>found the desire nor time.
However, there is this one pseudofile "security-password" which _is_
writable, what about it?
-`J'
--
Date: December 31, 2006
From: David Miller <davem@xxxxxxxxxxxxx>
In-reply-to:
<20061231154103.GA7409@xxxxxxxxxxxxx>
References:
<45978CE9.7090700@xxxxxxxx> <20061231.024917.59652177.davem@xxxxxxxxxxxxx> <20061231154103.GA7409@xxxxxxxxxxxxx>
From: Christoph Hellwig <hch@xxxxxxxxxxxxx> Date: Sun, 31 Dec 2006 15:41:03 +0000 > On Sun, Dec 31, 2006 at 02:49:17AM -0800, David Miller wrote: > > Am I the only person who sees something very wrong with this? > > No, I completely agree with you on this. > > If firmworks really wants to have a spearate filesystem that's fine. > But please start with the ppc or sparc code and massage it into a > a separate filesystem before adding support for a new platform. > > The last thing we need is more duplication. > > In case anyone wants to start this based on ppc I'd gladfully help > to test this on pmac (32 and 64bit) and cell (64 bit). Thanks for the vote of sanity Christoph. I'm happy to test on sparc64 of course too :-)
Date: December 31, 2006
From: David Miller <davem@xxxxxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.61.0612311350060.32449@xxxxxxxxxxxxxxx>
References:
<459714A6.4000406@xxxxxxxxxxxxx> <Pine.LNX.4.61.0612311350060.32449@xxxxxxxxxxxxxxx>
From: Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx> Date: Sun, 31 Dec 2006 15:12:26 +0100 (MET) > BUT, the eeprom utility may be used to modify values, and if used, I > would like to see ofwfs show the updated value. openpromfs does it > today: > > 15:09 ares:/proc/openprom/options # cat oem-banner? > false > 15:09 ares:/proc/openprom/options # eeprom 'oem-banner?=true' > 15:09 ares:/proc/openprom/options # cat oem-banner? > true > > (BTW, why does not openpromfs have it rw?) It used to be able to :-) When I changed sparc/sparc64 over to an in-memory copy of the OFW tree, I wasn't able to retain writable property support in openpromfs. It just needs to be implemented and I never found the desire nor time. Happily, everyone uses 'eeprom' or some other program accessing the tree via /dev/openprom to change values. I'm incredibly surprised how much resistence there is from the i386 OFW folks to do this right. It would be like 80 lines of code to suck the device tree into kernel memory, or if they don't want to do that they can use inline function wrappers to provide the clean C-language interface to all of this and the cost to i386-OFW would be zero with the benefit that other platforms could use the code potentially. Doing the same thing 3 different ways, knowingly, is just very bad engineering. That is how you end up with a big fat pile of unmaintainable poo instead of a clean maintainable source tree. If we fix a bug in one of these things, the other 2 are so different that if the bug is in the others we'll never know and it's not easy to check so people won't do it. So please do this crap right. Thanks.
Date: December 31, 2006
From: Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx>
In-reply-to:
<dd8f98f40612301053m17330fd2yf3c74e92ac0d47d5@xxxxxxxxxxxxxx>
References:
<OFE2F460D3.D19AD4FD-ON85257254.0056F820-85257254.00571E2D@xxxxxxxxxxxxxxxxxxxxxxxx> <45968B87.6090009@xxxxxxxxxxxxxxxxxxxxxxxxx> <dd8f98f40612301053m17330fd2yf3c74e92ac0d47d5@xxxxxxxxxxxxxx>
John R. wrote [in private mail]: > I've seen "RTOSes" that are little more than an idle loop with > cooperative multitasking up to stuff like QNX, VxWorks and RTLinux. Do > we have an idea of the actual dependencies on the RTOS of the mesh > networking code? > > Just curious if anyone has scoped out the actual OS dependencies... > for example, hard real time or not, multitasking, IPC, networking > support, etc.. Clearly there is a need for small size, but what else? Let's keep discussions on-list, please. -- Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx> | GPG: 0x147C722D
Date: December 31, 2006
From: Mitch Bradley <wmb@xxxxxxxxxxxxx>
In-reply-to:
<84144f020612310524u5e2e179esd5af4a11c1c1d2f8@xxxxxxxxxxxxxx>
References:
<459714A6.4000406@xxxxxxxxxxxxx> <84144f020612310524u5e2e179esd5af4a11c1c1d2f8@xxxxxxxxxxxxxx>
I made all the changes Pekka suggested, except:
That assignment turns out not to be redundant. If a security variable is recognized, you want the length to be 0 so as not to expose the password. In that case the following "getproplen" call won't be executed.+ security = strncmp(propname, "security-", 9) == 0;+ len = 0;Redundant assignment, no?+ if (!security)+ (void)callofw("getproplen", 2, 1, node, propname, &len);
That logic was adapted from the existing file fs/proc/devtree.c . It turns out that the code there has a bug: You really want to look for just "security-password" ; there is no need to, and good reasons not to, suppress the length of "security-mode" and "security-#badlogins". (Good OFW implementations won't leak the password length anyway, so check is only needed as a workaround).
I have rewritten the code for clarity and correctness thusly:
if (strcmp(propname, "security-password") == 0) {
len = 0; /* Don't leak password length */
} else {
callofw("getproplen", 2, 1, node, propname, &len);
}
Date: December 31, 2006
From: David Kahn <dmk@xxxxxxxx>
In-reply-to:
<200612270437.39874.arnd@xxxxxxxx>
References:
<458FAAFD.4050806@xxxxxxxxxxxxx> <1167087549.2938.13.camel@xxxxxxxxxxxxxxxxxxxxx> <4590FAD1.3020506@xxxxxxxxxxxxx> <200612270437.39874.arnd@xxxxxxxx>
Arnd Bergmann wrote:
Do you use the fs/proc/proc_devtree.c code right now with i386 specific additions for populating the tree, or did you write a completely separate implementation of /proc/device-tree?
We wrote a separate simple implementation of /proc/device-tree that just calls the OF cif. powerpc does some odd and complex stuff that wasn't needed and didn't really fit well. -David
Date: December 31, 2006
From: "John (J5) Palmieri" <johnp@xxxxxxxxxx>
In-reply-to:
<45972E7A.7010009@xxxxxxxxx>
References:
<45972E7A.7010009@xxxxxxxxx>
On Sat, 2006-12-30 at 19:28 -0800, Ian C. wrote: > hello > I have some software you may be interested in; it is a package > management system coded in python. > The project is called cap-python, it is a pretty basic system. > It is coded in a modular fashion so it can be tied into many different > interfaces and/or > an installer for the OS. Currently there is a beta version of a pygtk > interface for cap-python, > a screen shot of it is available at > http://arcanelinux.org/screenshots/cap-pygtk.jpg . > It has object oriented/modular repo database access code, so it can > access a variety of database formats both > local and remote while leaving the possibility for more. It currently > by default ties into the online > capsule repository web service. The online tools for cap-python can be > seen at http://caps.arcanelinux.org/ . Also the latest documentation > that was written for it can be found at > http://inc-omplete.org/wiki/index.php/Capsules/Documentation . > Thank you for your time, and please let us know if you are interested. While your packaging system is interesting in some respects our requirements are quite different from the traditional model pioneered by RPM and DEB's. It is perhaps the wrong level that we should be talking about. We are going in a direction of more self-contained applications which can simply be copied to a directory to get them to work. The base system itself, while being created via RPM's is installed and updated in other ways. The ondisk package database is there for developers and for people who really want to use packages in the fedora universe but for the most part will lay dormant. Dependencies will be simple dependencies on the base system build number itself and perhaps some sort of interdependency system for the activity bundles if needed. However I would like to avoid that if possible since the more complicated we get the more things can go wrong. -- John (J5) Palmieri <johnp@xxxxxxxxxx>
Date: December 31, 2006
From: Michail Bletsas <mbletsas@xxxxxxxxxx>
In-reply-to:
<5d043c010612310825s5c6218dei17153691c91ce7d0@xxxxxxxxxxxxxx>
References:
<5d043c010612310825s5c6218dei17153691c91ce7d0@xxxxxxxxxxxxxx>
| "Gabor Dolla"
<agdolla@xxxxxxxxx>
12/31/2006 11:25 AM |
|
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: December 31, 2006
From: "Gabor Dolla" <agdolla@xxxxxxxxx>
In-reply-to:
<OF5D3C010C.F00AE62F-ON85257255.004A401E-85257255.005019B7@xxxxxxxxxxxxxxxxxxxxxxxx>
References:
<5d043c010612301312u3caa1d18j2f87dee58a58573b@xxxxxxxxxxxxxx> <OF5D3C010C.F00AE62F-ON85257255.004A401E-85257255.005019B7@xxxxxxxxxxxxxxxxxxxxxxxx>
end of February. In parallel we are working with Marvell to release the 802.11s source code under GPL.
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: December 31, 2006
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
In-reply-to:
<20061231.024917.59652177.davem@xxxxxxxxxxxxx>
References:
<20061230.211941.74748799.davem@xxxxxxxxxxxxx> <459784AD.1010308@xxxxxxxxxxxxx> <45978CE9.7090700@xxxxxxxx> <20061231.024917.59652177.davem@xxxxxxxxxxxxx>
On Sun, Dec 31, 2006 at 02:49:17AM -0800, David Miller wrote: > From: David Kahn <dmk@xxxxxxxx> > Date: Sun, 31 Dec 2006 02:11:53 -0800 > > > All we've done is created a trivial implementation for exporting > > the device tree to userland that isn't burdened by the powerpc > > and sparc legacy code that's in there now. > > So now we'll have _3_ different implementations of exporting > the OFW device tree via procfs. Your's, the proc_devtree > of powerpc, and sparc's /proc/openprom > > That doesn't make any sense to me, having 3 ways of doing the same > exact thing and making no attempt to share code at all. > > If you want to do something new that consolidates everything, with the > goal of deprecating the existing stuff, that's great! But with they > way you're doing this, all the sparc and powerpc implementations > really can't take advantage of it. > > Am I the only person who sees something very wrong with this? No, I completely agree with you on this. If firmworks really wants to have a spearate filesystem that's fine. But please start with the ppc or sparc code and massage it into a a separate filesystem before adding support for a new platform. The last thing we need is more duplication. In case anyone wants to start this based on ppc I'd gladfully help to test this on pmac (32 and 64bit) and cell (64 bit).
Date: December 31, 2006
From: Michail Bletsas <mbletsas@xxxxxxxxxx>
In-reply-to:
<5d043c010612301312u3caa1d18j2f87dee58a58573b@xxxxxxxxxxxxxx>
References:
<5d043c010612301312u3caa1d18j2f87dee58a58573b@xxxxxxxxxxxxxx>
| "Gabor Dolla"
<agdolla@xxxxxxxxx>
12/30/2006 04:12 PM |
|
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: December 31, 2006
From: Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx>
In-reply-to:
<459714A6.4000406@xxxxxxxxxxxxx>
References:
<459714A6.4000406@xxxxxxxxxxxxx>
On Dec 30 2006 15:38, Mitch Bradley wrote:
>
> Request for comments.
>
> It is similar in some respect to fs/proc/proc_devtree.c , but does
> not use procfs, nor does it require an intermediate layer of code
> to create a flattened representation of the device tree.
NB: openpromfs does not use procfs either. It just happens to be
mounted somewhere down there.
> +++ b/Documentation/filesystems/ofwfs.txt
> +== Property Value Encoding ==
> +
> +A regular file in ofwfs contains the exact byte sequence that
> +comprises the OFW property value. Properties are not reformatted
> +into text form, so numeric property values appear as binary
> +integers. While this is inconvenient for viewing, it is generally
> +easier for programs that read property values, and it means that
> +Open Firmware documentation about property values applies
> +directly, without having to separately document an ASCII
> +transformation (which would have to separately specified for
> +different kinds of properties).
I appreciate the ASCII formatting that openpromfs currently does.
Perhaps, should OFWFS be used, it could offer both?
> +== Environment Assumptions ==
> +
> +The ofwfs code assumes that the Open Firmware client interface
> +callback can be executed during Linux kernel startup
> +(specifically, at "core_initcall" time). When ofwfs is
> +initialized, it copies out the property values, so that subsequent
> +accesses to the tree do not require callbacks into OFW.
openpromfs also has many parts read-only, only one object,
/options/security-password, is writable. Hence caching it once and
forever seems ok.
BUT, the eeprom utility may be used to modify values, and if used, I
would like to see ofwfs show the updated value. openpromfs does it
today:
15:09 ares:/proc/openprom/options # cat oem-banner?
false
15:09 ares:/proc/openprom/options # eeprom 'oem-banner?=true'
15:09 ares:/proc/openprom/options # cat oem-banner?
true
(BTW, why does not openpromfs have it rw?)
> +== Recommended Mount Point ==
> +
> +The recommended mount point for ofwfs is /ofw. (TBD: Should it be
> +mounted somewhere under /sys instead?)
Somewhere in /sys/firmware perhaps.
-`J'
--
Date: December 31, 2006
From: Rob Savoye <rob@xxxxxxxxxxxxxxx>
In-reply-to:
<5d043c010612301312u3caa1d18j2f87dee58a58573b@xxxxxxxxxxxxxx>
References:
<OFE2F460D3.D19AD4FD-ON85257254.0056F820-85257254.00571E2D@xxxxxxxxxxxxxxxxxxxxxxxx> <1167495099.4868.289.camel@localhost
> <5d043c010612301312u3caa1d18j2f87dee58a58573b@xxxxxxxxxxxxxx>
Gabor Dolla wrote:
When I asked the size of the current code I meant the size of the source code not the binary... How many lines of source code ?Is the source code documented or commented ?
I agree this is probably better as a longer term goal, than trying to get done right away. I'm not sure how many lines the source code is, but it is well documented and commented. A little history... We originally designed eCOS at Cygnus, to give us a complete software stack for embedded systems. Many of our customers needed something more hard-real time to replace their roll-your-own kernels. We also made eCOS support other RTOS APIs, like Micro-Itron, so eCOS is very heavily used by Japanese industry these days. To ensure a solid product, we developed a solid testing infrastructure, good documentation, and the configuration infrastructure.
Redhat decided to get out of the embedded systems business at one point after they bought Cygnus, and so the eCOS team I had built setup their own company, eCosCentric in Cambridge to support eCOS. They are now the primary developers and maintainers of eCOS, and I'd suggest utilizing their expertise for a project like this if possible.
- rob -
Date: December 31, 2006
From: Michail Bletsas <mbletsas@xxxxxxxxxx>
In-reply-to:
<4596F0B5.7030203@xxxxxxxxxxxxx>
References:
<4596F0B5.7030203@xxxxxxxxxxxxx>
| Andi <andi@xxxxxxxxxxxxx>
12/30/2006 06:05 PM |
|
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: December 31, 2006
From: "Pekka Enberg" <penberg@xxxxxxxxxxxxxx>
In-reply-to:
<459714A6.4000406@xxxxxxxxxxxxx>
References:
<459714A6.4000406@xxxxxxxxxxxxx>
On 12/31/06, Mitch Bradley <wmb@xxxxxxxxxxxxx> wrote:
diff --git a/arch/i386/kernel/ofw_fs.c b/arch/i386/kernel/ofw_fs.c new file mode 100644 index 0000000..30ca359 --- /dev/null +++ b/arch/i386/kernel/ofw_fs.c @@ -0,0 +1,261 @@ +/* 1275 in little-endian ASCII (for IEEE 1275 - the Open Firmware Standard) */ +#define OFWFS_MAGIC 0x35373231
Please put this in <linux/magic.h> On 12/31/06, Mitch Bradley <wmb@xxxxxxxxxxxxx> wrote:
+ case S_IFREG: + inode->i_fop = &ofwfs_property_operations; + inode->i_bytes = ((struct propval *)data)->length; + inode->i_size = (loff_t)(((struct propval *)data)->length);
As you need the struct twice, use a local variable. On 12/31/06, Mitch Bradley <wmb@xxxxxxxxxxxxx> wrote:
+static int ofwfs_create_props(struct super_block *sb, struct dentry *dir,
+ phandle node)
+{
+ char propname[32];
+ int security, len;
+ struct propval *propval;
+ int ret = 0;
+ int flag;
+
+ propname[0] = '\0';
+
+ while ((void)callofw("nextprop", 3, 1, node, propname, propname,
+ &flag), flag == 1) {
Please do the call within the loop body and use an explicit bereak.
+ security = strncmp(propname, "security-", 9) == 0; + len = 0;
Redundant assignment, no?
+ if (!security)
+ (void)callofw("getproplen", 2, 1, node, propname, &len);
We don't use void casts to suppress return value in Linux. You can just drop it (elsewhere too). On 12/31/06, Mitch Bradley <wmb@xxxxxxxxxxxxx> wrote:
+out:
+ if (ret) {
+ WARN_ON(1);
+/*
+ ofwfs_remove_props(sb, dir);
+*/
+ }
Hmm? On 12/31/06, Mitch Bradley <wmb@xxxxxxxxxxxxx> wrote:
+static int __init ofwfs_init(void)
+{
+ int ret;
+
+ ret = register_filesystem(&ofwfs_type);
+ if (ret)
+ return ret;
+
+ kern_mount(&ofwfs_type);
kern_mount can fail so you'd better do IS_ERR/PTR_ERR here.
diff --git a/include/asm-i386/callofw.h b/include/asm-i386/callofw.h new file mode 100644 index 0000000..594cb63 --- /dev/null +++ b/include/asm-i386/callofw.h +#include <linux/types.h> + +typedef void *phandle;
The typedef seems useless and confusing at best. Can we drop it?
Date: December 31, 2006
From: Rene Rebe <rene@xxxxxxxxxxxx>
In-reply-to:
<20061231.024917.59652177.davem@xxxxxxxxxxxxx>
References:
<20061230.211941.74748799.davem@xxxxxxxxxxxxx> <45978CE9.7090700@xxxxxxxx> <20061231.024917.59652177.davem@xxxxxxxxxxxxx>
Hi, On Sunday 31 December 2006 11:49, David Miller wrote: > From: David Kahn <dmk@xxxxxxxx> > Date: Sun, 31 Dec 2006 02:11:53 -0800 > > > All we've done is created a trivial implementation for exporting > > the device tree to userland that isn't burdened by the powerpc > > and sparc legacy code that's in there now. > > So now we'll have _3_ different implementations of exporting > the OFW device tree via procfs. Your's, the proc_devtree > of powerpc, and sparc's /proc/openprom > > That doesn't make any sense to me, having 3 ways of doing the same > exact thing and making no attempt to share code at all. > > If you want to do something new that consolidates everything, with the > goal of deprecating the existing stuff, that's great! But with they > way you're doing this, all the sparc and powerpc implementations > really can't take advantage of it. > > Am I the only person who sees something very wrong with this? Nope you aren't, ACK to a unified user-space export from my side as well. Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45
Date: December 31, 2006
From: David Kahn <dmk@xxxxxxxx>
In-reply-to:
<20061231.024917.59652177.davem@xxxxxxxxxxxxx>
References:
<20061230.211941.74748799.davem@xxxxxxxxxxxxx> <459784AD.1010308@xxxxxxxxxxxxx> <45978CE9.7090700@xxxxxxxx> <20061231.024917.59652177.davem@xxxxxxxxxxxxx>
David Miller wrote:
From: David Kahn <dmk@xxxxxxxx> Date: Sun, 31 Dec 2006 02:11:53 -0800All we've done is created a trivial implementation for exporting the device tree to userland that isn't burdened by the powerpc and sparc legacy code that's in there now.So now we'll have _3_ different implementations of exporting the OFW device tree via procfs. Your's, the proc_devtree of powerpc, and sparc's /proc/openprom
I would not exactly call what we have for powerpc "exporting the OFW device tree". I don't quite know what it is, but it isn't as simple as exporting the OFW device tree. I don't think we really wanted to get into any of that here.
If you want to do something new that consolidates everything, with the goal of deprecating the existing stuff, that's great! But with they way you're doing this, all the sparc and powerpc implementations really can't take advantage of it.
Sure they can take advantage of it, if what they need to export is a read-only copy of the actual device tree without any legacy burden or having a writable/changeable copy of it with a trivial implementation. But that's not up to us, and that's not what's been done for powerpc and sparc. This is a trivial implementation that suits it's purpose. It's simple. I'm not sure what more is needed for this project when it's pretty clear that i386 will never need any additional support for open firmware. -David
Date: December 31, 2006
From: "jk" <jk@xxxxxxxxxxxx>
References:
<20061231091802.B808CEF81DF@xxxxxxxxxxxxxxxx>
Dear OLPC team,
We wish you all very best 2007.
Kind Regards
jk
>From Bangalore, India
http://www.epigon.in/
----- Original Message -----
From: <devel-request@xxxxxxxxxx>
To: <devel@xxxxxxxxxx>
Sent: Sunday, December 31, 2006 2:48 PM
Subject: Devel Digest, Vol 10, Issue 39
> Send Devel mailing list submissions to
> devel@xxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.laptop.org/mailman/listinfo/devel
> or, via email, send a message with subject or body 'help' to
> devel-request@xxxxxxxxxx
>
> You can reach the person managing the list at
> devel-owner@xxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Devel digest..."
>
>
> Today's Topics:
>
> 1. Re: OLPC Laptop - an open source substandard ? (Alex Gibson)
> 2. package system for the OLPC (Ian C.)
> 3. Re: OLPC Laptop - an open source substandard ? ( ticket #46 )
> (Alex Gibson)
> 4. Re: OLPC Laptop - an open source substandard ? (Jim Gettys)
> 5. Re: OLPC Laptop - an open source substandard ? (Alex Gibson)
> 6. Re: [PATCH] Open Firmware device tree virtual filesystem
> (David Miller)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 31 Dec 2006 14:13:34 +1100
> From: Alex Gibson <agibson@xxxxxxxxxxxxxx>
> Subject: Re: OLPC Laptop - an open source substandard ?
> To: devel@xxxxxxxxxx
> Message-ID: <45972ADE.9000706@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> Ivan KrstiÄ? wrote:
> > Michail Bletsas wrote:
> >
> >> The issue is that we need working code now and we have to rely on
> >> whatever RTOS people that can deliver code under hard deadlines feel
> >> comfortable working with.
> >>
> >
> > Right, but this is a different discussion -- as per ticket #46
> > (http://dev.laptop.org/ticket/46), about getting the Marvell code under
> > NDA to someone for porting.
> >
> > Previously, there was no known suitable (free) porting target. Now eCOS
> > has emerged as one.
> >
> >
>
> There are a few
>
> ecos - ecos.sourceware.org
> modified gpl http://ecos.sourceware.org/license-overview.html
>
> freertos - www.freertos.org
> modified gpl
>
> tinyos - http://www.freertos.org/a00114.html
> license ? http://www.tinyos.net/faq.html#SEC-17
>
> Any other suitable open source rtos ?
>
> Do the licenses linked to above, meet the requirements ?
>
> Michail, what are the deadlines ?
>
> I know the group head of ICT Engineering (Information and Communications
> Technology)
> has had a talk with the local Marvell rep on getting an NDA signed.
>
> I'll have a talk with him at the open day on the 3rd and see if we can
> get this sped up.
> Unfortunately a lot of companies here shutdown for summer holidays until
> the end of janurary , so
> we'll have to see what we can do.
> (summer school holidays 13 dec - 3rd feb)
> (uni holidays end of nov - march - full three months for students)
>
> I'm an interested in having a go but can not commit to any deadlines as
> am working
> full time for a research lab/company until the end of January
> on license plate recognition systems and deployments.
>
> May be better placed to assist with testing of a driver
> as we have a full communications testing lab which is not currently being
> utilised. Have equipment for up to 50GHz.
>
> Has anyone started looking at repeaters or message box storage or
> internet gateways yet ?
>
>
> Alex Gibson
>
> Technical Officer
> Network Sensor Technologies Laboratory
> University of Technology Sydney
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://mailman.laptop.org/pipermail/devel/attachments/20061231/61f8b681/atta
chment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Sat, 30 Dec 2006 19:28:58 -0800
> From: "Ian C." <inchosting@xxxxxxxxx>
> Subject: package system for the OLPC
> To: devel@xxxxxxxxxx
> Message-ID: <45972E7A.7010009@xxxxxxxxx>
> Content-Type: text/plain; charset="iso-8859-1"
>
> hello
> I have some software you may be interested in; it is a package
> management system coded in python.
> The project is called cap-python, it is a pretty basic system.
> It is coded in a modular fashion so it can be tied into many different
> interfaces and/or
> an installer for the OS. Currently there is a beta version of a pygtk
> interface for cap-python,
> a screen shot of it is available at
> http://arcanelinux.org/screenshots/cap-pygtk.jpg .
> It has object oriented/modular repo database access code, so it can
> access a variety of database formats both
> local and remote while leaving the possibility for more. It currently by
> default ties into the online
> capsule repository web service. The online tools for cap-python can be
> seen at http://caps.arcanelinux.org/ . Also the latest documentation
> that was written for it can be found at
> http://inc-omplete.org/wiki/index.php/Capsules/Documentation .
> <http://inc-omplete.org/wiki/index.php/Capsules/Documentation>
> Thank you for your time, and please let us know if you are interested.
> --Ian "Inc" C.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://mailman.laptop.org/pipermail/devel/attachments/20061230/16f49667/atta
chment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Sun, 31 Dec 2006 14:27:29 +1100
> From: Alex Gibson <agibson@xxxxxxxxxxxxxx>
> Subject: Re: OLPC Laptop - an open source substandard ? ( ticket #46 )
> To: devel@xxxxxxxxxx
> Message-ID: <45972E21.9060909@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-15
>
> Andi wrote:
> > Hi Jim, Hi list,
> >
> > Jim Gettys wrote:
> >> Unless that investment can be done in parallel, this change translates
> >> into delay and cost. Right now, there are only one set of people
> >> familiar with the mesh code, working under a tight deadline. We're not
> >> about to tell them to delay the overall project by switching horses in
> >> midstream.
> >>
> >> So to break the conundrum there also have to be people willing to
> >> actually do the work, as the primary firmware team is working on
getting
> >> us code we can use and deploy.
> > ...
> >> As in the base system BIOS/firmware situation, the right way to look at
> >> this is we know the desired/needed end-state, and to take steps toward
> >> that state as time and resources permit.
> >
> > That's good news.
> > Basically you say that you will *support* a parallel development, if
> > there are people willing to do a parallel development.
> > OK.
> > What's needed to start:
> > - a cheap and easy to get development environment:
> > Since a BTest-1 Systems is still a hard to get thing...
> > In what cheap device, *sold* *worldwide*, is the Marvell Libertas
> > 88W8388 chip in a to the Gen1-System compatible manner build in ?
> > Candidates:
> > - Xbox 360 WifiAdapter http://wiki.free60.org/WifiAdapter
> > Start at 65 EUR
> > Could someone ask Marvell kindly about that please ?
> >
> > If we have OLPC Gen1-System compatible development hardware we could
> > evaluate the Marvell RTOS alternatives http://ecos.sourceware.org/ and
> > http://www.tinyos.net/
> >
> >
> > Andi
>
> Its a pity the gumstix.com guys used the 88W8385
> as their wifi stix board would have been perfect
> http://gumstix.com/store/catalog/product_info.php?products_id=172
> (I have a couple on my desk)
>
> There is an olsr package now available in their standard buildroot.
>
> But I don't think they do yet have that opensource driver they mention.
> They ran into the same problem with the firmware.
>
> May be worth while for someone to have a chat with them.
>
>
> Alex
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 30 Dec 2006 23:20:54 -0500
> From: Jim Gettys <jg@xxxxxxxxxx>
> Subject: Re: OLPC Laptop - an open source substandard ?
> To: Alex Gibson <agibson@xxxxxxxxxxxxxx>
> Cc: devel@xxxxxxxxxx
> Message-ID: <1167538854.4868.317.camel@localhost
>
> Content-Type: text/plain
>
> On Sun, 2006-12-31 at 14:13 +1100, Alex Gibson wrote:
>
> >
> > Michail, what are the deadlines ?
> >
>
> Our current deadlines are irrelevant to the discussion. We are not
> going to divert the current development to a different embedded system
> code base until and unless the alternative is equally functional. In
> this sense, there is no deadline. The networking is fundamental to the
> project.
>
> Different firmware can be deployed at essentially arbitrary future
> dates; obviously those will fold into future release schedules, but this
> is far enough out that the discussion of deadlines is academic.
> Best Regards,
> - Jim
>
>
> --
> Jim Gettys
> One Laptop Per Child
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 29 Dec 2006 12:46:40 +1100
> From: Alex Gibson <agibson@xxxxxxxxxxxxxx>
> Subject: Re: OLPC Laptop - an open source substandard ?
> To: devel@xxxxxxxxxx
> Message-ID: <45947380.6010102@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> Ivan KrstiÄ? wrote:
> > Gabor Dolla wrote:
> >
> >> - The goal to have an open source solution. If the code will be free
and
> >> available what is the purpose of NDA ?
> >>
> >
> > The meshing code is inextricable from the RTOS currently used, which is
> > commercial and proprietary. The RTOS is thus delivered as part of the
> > meshing code for porting, and protecting the RTOS requires an NDA.
> >
>
> The rtos is threadx ?
> >
> >> - Marvell would hand over the full specs of the chip including the
radio
> >> part ? AFAIK usually the radio part is kept as a secret to make
> >> regulators happy,,, Or the radio part would be in binary format ?
> >>
> >
> > Still being discussed.
> >
> >
> >> - 802.11 b/g is also implemented in software as in recent prism54 chips
> >> (soft MAC)? The open source solutions should cover that part too ?
> >>
> >
> > Not sure about this bit. Michalis?
> >
> >
> >> - An underlying OS (ticket suggest TinyOS) is really needed ?
> >>
> >
> > Yes. I've recently received the suggestion that eCos, which is GPL'd,
> > can be used for this purpose.
> >
> There is also free rtos - freertos.org
>
> Which has a port for arm9 (ports for arm7 as well) already like ecos
> does but the footprint is a bit smaller
> than ecos. Gives the choice of pre-emptive and co-operative real time
> kernels
>
> Its available under a modified gpl
> http://www.freertos.org/a00114.html
>
> Alex
> >
> >> - 802.11s or batman is preferred ?
> >>
> >
> > We've chosen to go with 802.11s.
> >
> >
> >> - 802.11i is in the scope ?
> >>
> >
> > Not initially, as far as I know.
> >
> >
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://mailman.laptop.org/pipermail/devel/attachments/20061229/ead82a9d/atta
chment.html
>
> ------------------------------
>
> Message: 6
> Date: Sat, 30 Dec 2006 21:19:41 -0800 (PST)
> From: David Miller <davem@xxxxxxxxxxxxx>
> Subject: Re: [PATCH] Open Firmware device tree virtual filesystem
> To: wmb@xxxxxxxxxxxxx
> Cc: linux-kernel@xxxxxxxxxxxxxxx, devel@xxxxxxxxxx
> Message-ID: <20061230.211941.74748799.davem@xxxxxxxxxxxxx>
> Content-Type: Text/Plain; charset=us-ascii
>
> From: Mitch Bradley <wmb@xxxxxxxxxxxxx>
> Date: Sat, 30 Dec 2006 15:38:46 -1000
>
> > Request for comments.
> >
> > This patch creates a virtual filesystem that represents an Open Firmware
> > device tree. It has been tested on an OLPC x86 system, but the code is
> > not processor-specific (apart from its current location under
arch/i386).
> >
> > It requires an Open Firmware implementation that can stay resident
during
> > Linux startup.
> >
> > It is similar in some respect to fs/proc/proc_devtree.c , but does not
> > use procfs, nor does it require an intermediate layer of code to
> > create a flattened representation of the device tree.
> >
> > The patch applies cleanly against the current version of
> > git://dev.laptop.org/olpc-2.6 . (commit
5b9429be6056864b938ff6f39e5df3cecbbfcf4b).
> >
> > Please cc me (Mitch Bradley <wmb@xxxxxxxxxxxxx>) on comments.
>
> Can we please not have N different interfaces to the open-firmware
> calls so that perhaps powerpc and Sparc have a chance of using this
> code too?
>
> On sparc and powerpc, we even build an in-kernel data structure of the
> entire open-firmware device tree that code like your's could use if
> you make a simple setup layer for i386 as well. We have interfaces for
> modifying property values at run time too.
>
> I would strongly suggest looking at things like
> arch/{sparc,sparc64,powerpc}/kernel/prom.c and
> include/asm-{sparc,sparc64,powerpc}/prom.h and
> arch/{sparc,sparc64,powerpc}/kernel/of_device.c and
> include/asm-{sparc,sparc64,powerpc}/of_device.h
> since we've already invested a lot of thought and
> infrastructure into providing interfaces to this information
> on powerpc and the two sparc platforms.
>
> Thanks.
>
>
> ------------------------------
>
> _______________________________________________
> Devel mailing list
> Devel@xxxxxxxxxx
> http://mailman.laptop.org/mailman/listinfo/devel
>
>
> End of Devel Digest, Vol 10, Issue 39
> *************************************
>
Date: December 31, 2006
From: David Miller <davem@xxxxxxxxxxxxx>
In-reply-to:
<45978CE9.7090700@xxxxxxxx>
References:
<20061230.211941.74748799.davem@xxxxxxxxxxxxx> <459784AD.1010308@xxxxxxxxxxxxx> <45978CE9.7090700@xxxxxxxx>
From: David Kahn <dmk@xxxxxxxx> Date: Sun, 31 Dec 2006 02:11:53 -0800 > All we've done is created a trivial implementation for exporting > the device tree to userland that isn't burdened by the powerpc > and sparc legacy code that's in there now. So now we'll have _3_ different implementations of exporting the OFW device tree via procfs. Your's, the proc_devtree of powerpc, and sparc's /proc/openprom That doesn't make any sense to me, having 3 ways of doing the same exact thing and making no attempt to share code at all. If you want to do something new that consolidates everything, with the goal of deprecating the existing stuff, that's great! But with they way you're doing this, all the sparc and powerpc implementations really can't take advantage of it. Am I the only person who sees something very wrong with this?
Date: December 31, 2006
From: David Kahn <dmk@xxxxxxxx>
In-reply-to:
<459784AD.1010308@xxxxxxxxxxxxx>
References:
<459714A6.4000406@xxxxxxxxxxxxx> <20061230.211941.74748799.davem@xxxxxxxxxxxxx> <459784AD.1010308@xxxxxxxxxxxxx>
Responding to two replies in one email ... Mitch Bradley wrote:
David Miller wrote:... Can we please not have N different interfaces to the open-firmware calls so that perhaps powerpc and Sparc have a chance of using this code too?
David, I helped Mitch do this "port", so I'd like to chime in here. Mitch and I both looked extensively at the powerpc and sparc code that's there. There's an entire extra layer there that isn't needed if all you want to do is expose the device tree to userland via the file system, and that's all that was needed in this case, plus, the desire is to keep OFW in memory in this case, so caching of the device tree is unnecessary for this simple implementation. We didn't create a new interface here, all we did was write code for the existing OFW client interface and call it directly, rather than go through extra layers of code to do that.Both the existing powerpc and sparc code seems to be burdened with the use of legacy interfaces. David Miller wrote:
Please create explicit function calls for each operation, this way the caller is immune to open-firmware implementation details.
I did that initially, but Mitch and I agreed that it's just a waste of more code for this case, where the majority of i386 implementations are not going to use it. The opportunity for layering an interface in between the kernel and the firmware still exists with the trivial callofw interface.
SPARC should be able to use that same base interface function directly. It is written to the standard OFW client interface.Sparc 32-bit predates the OFW specification and does things differently.
15 year old 32-bit SPARC machines use a different interface. None of those machines are even supported by Sun anymore (hardware or software support in any form.) Nonetheless, we haven't changed any of that. And by the way, Mitch and I are intimately familiar with that stuff from our days together at Sun. (I'm still at Sun.) Mitch and I have worked together on these firmware interfaces for a long time now.
Please use a functional interface using a C function for each device tree operation, then the implementation behind it doesn't matter.
The opportunity for layering a different interface in between the kernel and the firmware already exists with the callofw and cif_handler interfaces. In fact, before Mitch got the code working, I had written an entire emulation layer to test the file system code out. All it did was hook into that existing cif_handler interface, providing its own address rather than using a cif handler address in the firmware. At the end of the day, Mitch got the cif calls working to the actual firmware before we tried the emulation layer, but the point is that it was fairly trivial to implement.
It wouldn't work on ancient Sun machines with the sunmon romvec interface, but Sun stopped making such machines something like 16 years ago.Yet we still support them in the 32-bit sparc port. And it's so easy to support this properly, please use the clean stuff we've created for this.
We haven't changed the sparc implementation, it all still works. All we've done is created a trivial implementation for exporting the device tree to userland that isn't burdened by the powerpc and sparc legacy code that's in there now.
I did consider first creating a memory data structure identical to the powerpc/sparc one, but that looked like it was going to be essentially twice as much code for no extra capability. The code to traverse the device tree and create the memory data structure is roughly the same as the code to create the filesystem structure. I just didn't see the value of an intermediate representation for systems that don't otherwise need it.Since we put it in memory, we have zero reason to call into the firmware for device tree access and this simplifies things a lot.
And it also wastes resources, if all you need is a read-only view of the device tree in the filesystem. -David
Date: December 31, 2006
From: David Miller <davem@xxxxxxxxxxxxx>
In-reply-to:
<459784AD.1010308@xxxxxxxxxxxxx>
References:
<459714A6.4000406@xxxxxxxxxxxxx> <20061230.211941.74748799.davem@xxxxxxxxxxxxx> <459784AD.1010308@xxxxxxxxxxxxx>
From: Mitch Bradley <wmb@xxxxxxxxxxxxx> Date: Sat, 30 Dec 2006 23:36:45 -1000 > The base interface function is callofw(), which is effectively identical > to call_prom_ret() in arch/powerpc/kernel/prom_init.c . So it seems > that PowerPC could use it. I suppose I could change the name of > callofw() to call_prom_ret(), thus making the base interface identical > to PowerPC's. All it does is argument marshalling, translating between > C varargs argument lists and the OFW argarray format. Please create explicit function calls for each operation, this way the caller is immune to open-firmware implementation details. > SPARC should be able to use that same base interface function directly. > It is written to the standard OFW client interface. Sparc 32-bit predates the OFW specification and does things differently. Please use a functional interface using a C function for each device tree operation, then the implementation behind it doesn't matter. > It wouldn't work on ancient Sun machines with the sunmon romvec > interface, but Sun stopped making such machines something like 16 years ago. Yet we still support them in the 32-bit sparc port. And it's so easy to support this properly, please use the clean stuff we've created for this. > I did consider first creating a memory data structure identical to the > powerpc/sparc one, but that looked like it was going to be essentially > twice as much code for no extra capability. The code to traverse the > device tree and create the memory data structure is roughly the same as > the code to create the filesystem structure. I just didn't see the > value of an intermediate representation for systems that don't otherwise > need it. Since we put it in memory, we have zero reason to call into the firmware for device tree access and this simplifies things a lot. But all of that really doesn't matter, if you use a functional C interface for each device tree access operation, it doesn't matter what's behind it right?
Date: December 31, 2006
From: Mitch Bradley <wmb@xxxxxxxxxxxxx>
In-reply-to:
<20061230.211941.74748799.davem@xxxxxxxxxxxxx>
References:
<459714A6.4000406@xxxxxxxxxxxxx> <20061230.211941.74748799.davem@xxxxxxxxxxxxx>
David Miller wrote:
The base interface function is callofw(), which is effectively identical to call_prom_ret() in arch/powerpc/kernel/prom_init.c . So it seems that PowerPC could use it. I suppose I could change the name of callofw() to call_prom_ret(), thus making the base interface identical to PowerPC's. All it does is argument marshalling, translating between C varargs argument lists and the OFW argarray format.... Can we please not have N different interfaces to the open-firmware calls so that perhaps powerpc and Sparc have a chance of using this code too?
SPARC should be able to use that same base interface function directly. It is written to the standard OFW client interface. The x86 client interface that I tested it on is essentially the same code that is in OBP. It wouldn't work on ancient Sun machines with the sunmon romvec interface, but Sun stopped making such machines something like 16 years ago.
On sparc and powerpc, we even build an in-kernel data structure of the
entire open-firmware device tree that code like your's could use if
you make a simple setup layer for i386 as well. We have interfaces for
modifying property values at run time too.
I would strongly suggest looking at things like
arch/{sparc,sparc64,powerpc}/kernel/prom.c and
include/asm-{sparc,sparc64,powerpc}/prom.h and
arch/{sparc,sparc64,powerpc}/kernel/of_device.c and
include/asm-{sparc,sparc64,powerpc}/of_device.h
since we've already invested a lot of thought and
infrastructure into providing interfaces to this information
on powerpc and the two sparc platforms.
In contrast, ofw_fs.c is 261 lines, and the base interface function callofw() is 97 lines (half of them comments).
Admittedly, this is something of an apples-to-oranges comparison, because ofw_fs only exports a read-only device tree and nothing else. But in the case where that is all you need, a direct interface to OFW that avoids the middleman seems like a good choice.
I did consider first creating a memory data structure identical to the powerpc/sparc one, but that looked like it was going to be essentially twice as much code for no extra capability. The code to traverse the device tree and create the memory data structure is roughly the same as the code to create the filesystem structure. I just didn't see the value of an intermediate representation for systems that don't otherwise need it. (A setup layer would have let me use proc_devtree.c directly, so the total amount of new code would have been the same, but many people told me that if I even suggested using procfs the kernel gurus would blow me out of the water without bothering to blink.)
In the SPARC and PowerPC spaces, Open Firmware is widespread, so it makes sense for those kernels to use OFW extensively. In x86 land, OFW is far from being the dominant firmware, so the x86 kernel is unlikely to depend on OFW services at a deep level. That being the case, the deep-integration features of the sparc and powerpc OFW interfaces are not needed in x86 land. But a lightweight interface to the device tree is certainly useful for the platforms that do have OFW. It might be useful for other processors as well, especially on platforms that don't need the deep configurability that drove the OFW design.
Date: December 31, 2006
From: Alex Gibson <agibson@xxxxxxxxxxxxxx>
In-reply-to:
<459437ED.8020609@xxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061221134302.22500@xxxxxxx> <20061221141419.22500@xxxxxxx> <20061223101607.217580@xxxxxxx> <458D1842.6060509@xxxxxxx> <5d043c010612280121h6051b8d5o37c74065a04b2991@xxxxxxxxxxxxxx> <4593F5BA.1030302@xxxxxxxxxxxxxxxxxxxxxxxxx> <5d043c010612281149u7ddd60e3r97e8438abb4bc6a2@xxxxxxxxxxxxxx> <459437ED.8020609@xxxxxxxxxxxxxxxxxxxxxxxxx>
Ivan Krstić wrote:
Gabor Dolla wrote: The rtos is threadx ? There is also free rtos - freertos.org Which has a port for arm9 (ports for arm7 as well) already like ecos does but the footprint is a bit smaller than ecos. Gives the choice of pre-emptive and co-operative real time kernels Its available under a modified gpl http://www.freertos.org/a00114.html Alex
|
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: December 31, 2006
From: David Miller <davem@xxxxxxxxxxxxx>
In-reply-to:
<459714A6.4000406@xxxxxxxxxxxxx>
References:
<459714A6.4000406@xxxxxxxxxxxxx>
From: Mitch Bradley <wmb@xxxxxxxxxxxxx>
Date: Sat, 30 Dec 2006 15:38:46 -1000
> Request for comments.
>
> This patch creates a virtual filesystem that represents an Open Firmware
> device tree. It has been tested on an OLPC x86 system, but the code is
> not processor-specific (apart from its current location under arch/i386).
>
> It requires an Open Firmware implementation that can stay resident during
> Linux startup.
>
> It is similar in some respect to fs/proc/proc_devtree.c , but does not
> use procfs, nor does it require an intermediate layer of code to
> create a flattened representation of the device tree.
>
> The patch applies cleanly against the current version of
> git://dev.laptop.org/olpc-2.6 . (commit
> 5b9429be6056864b938ff6f39e5df3cecbbfcf4b).
>
> Please cc me (Mitch Bradley <wmb@xxxxxxxxxxxxx>) on comments.
Can we please not have N different interfaces to the open-firmware
calls so that perhaps powerpc and Sparc have a chance of using this
code too?
On sparc and powerpc, we even build an in-kernel data structure of the
entire open-firmware device tree that code like your's could use if
you make a simple setup layer for i386 as well. We have interfaces for
modifying property values at run time too.
I would strongly suggest looking at things like
arch/{sparc,sparc64,powerpc}/kernel/prom.c and
include/asm-{sparc,sparc64,powerpc}/prom.h and
arch/{sparc,sparc64,powerpc}/kernel/of_device.c and
include/asm-{sparc,sparc64,powerpc}/of_device.h
since we've already invested a lot of thought and
infrastructure into providing interfaces to this information
on powerpc and the two sparc platforms.
Thanks.
Date: December 31, 2006
From: Jim Gettys <jg@xxxxxxxxxx>
In-reply-to:
<45972ADE.9000706@xxxxxxxxxxxxxx>
References:
<OFE2F460D3.D19AD4FD-ON85257254.0056F820-85257254.00571E2D@xxxxxxxxxxxxxxxxxxxxxxxx> <45968B87.6090009@xxxxxxxxxxxxxxxxxxxxxxxxx> <45972ADE.9000706@xxxxxxxxxxxxxx>
On Sun, 2006-12-31 at 14:13 +1100, Alex Gibson wrote:
>
> Michail, what are the deadlines ?
>
Our current deadlines are irrelevant to the discussion. We are not
going to divert the current development to a different embedded system
code base until and unless the alternative is equally functional. In
this sense, there is no deadline. The networking is fundamental to the
project.
Different firmware can be deployed at essentially arbitrary future
dates; obviously those will fold into future release schedules, but this
is far enough out that the discussion of deadlines is academic.
Best Regards,
- Jim
--
Jim Gettys
One Laptop Per Child
Date: December 31, 2006
From: Alex Gibson <agibson@xxxxxxxxxxxxxx>
In-reply-to:
<4596F0B5.7030203@xxxxxxxxxxxxx>
References:
<OFE2F460D3.D19AD4FD-ON85257254.0056F820-85257254.00571E2D@xxxxxxxxxxxxxxxxxxxxxxxx> <1167495099.4868.289.camel@localhost
> <4596F0B5.7030203@xxxxxxxxxxxxx>
Andi wrote: > Hi Jim, Hi list, > > Jim Gettys wrote: >> Unless that investment can be done in parallel, this change translates >> into delay and cost. Right now, there are only one set of people >> familiar with the mesh code, working under a tight deadline. We're not >> about to tell them to delay the overall project by switching horses in >> midstream. >> >> So to break the conundrum there also have to be people willing to >> actually do the work, as the primary firmware team is working on getting >> us code we can use and deploy. > ... >> As in the base system BIOS/firmware situation, the right way to look at >> this is we know the desired/needed end-state, and to take steps toward >> that state as time and resources permit. > > That's good news. > Basically you say that you will *support* a parallel development, if > there are people willing to do a parallel development. > OK. > What's needed to start: > - a cheap and easy to get development environment: > Since a BTest-1 Systems is still a hard to get thing... > In what cheap device, *sold* *worldwide*, is the Marvell Libertas > 88W8388 chip in a to the Gen1-System compatible manner build in ? > Candidates: > - Xbox 360 WifiAdapter http://wiki.free60.org/WifiAdapter > Start at 65 EUR > Could someone ask Marvell kindly about that please ? > > If we have OLPC Gen1-System compatible development hardware we could > evaluate the Marvell RTOS alternatives http://ecos.sourceware.org/ and > http://www.tinyos.net/ > > > Andi Its a pity the gumstix.com guys used the 88W8385 as their wifi stix board would have been perfect http://gumstix.com/store/catalog/product_info.php?products_id=172 (I have a couple on my desk) There is an olsr package now available in their standard buildroot. But I don't think they do yet have that opensource driver they mention. They ran into the same problem with the firmware. May be worth while for someone to have a chat with them. Alex
Date: December 31, 2006
From: "Ian C." <inchosting@xxxxxxxxx>
|
hello I have some software you may be interested in; it is a package management system coded in python. The project is called cap-python, it is a pretty basic system. It is coded in a modular fashion so it can be tied into many different interfaces and/or an installer for the OS. Currently there is a beta version of a pygtk interface for cap-python, a screen shot of it is available at http://arcanelinux.org/screenshots/cap-pygtk.jpg . It has object oriented/modular repo database access code, so it can access a variety of database formats both local and remote while leaving the possibility for more. It currently by default ties into the online capsule repository web service. The online tools for cap-python can be seen at http://caps.arcanelinux.org/ . Also the latest documentation that was written for it can be found at http://inc-omplete.org/wiki/index.php/Capsules/Documentation . Thank you for your time, and please let us know if you are interested. --Ian "Inc" C. |
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: December 31, 2006
From: Alex Gibson <agibson@xxxxxxxxxxxxxx>
In-reply-to:
<45968B87.6090009@xxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<OFE2F460D3.D19AD4FD-ON85257254.0056F820-85257254.00571E2D@xxxxxxxxxxxxxxxxxxxxxxxx> <45968B87.6090009@xxxxxxxxxxxxxxxxxxxxxxxxx>
Ivan Krstić wrote:
Michail Bletsas wrote: There are a few ecos - ecos.sourceware.org modified gpl http://ecos.sourceware.org/license-overview.html freertos - www.freertos.org modified gpl tinyos - http://www.freertos.org/a00114.html license ? http://www.tinyos.net/faq.html#SEC-17 Any other suitable open source rtos ? Do the licenses linked to above, meet the requirements ? Michail, what are the deadlines ? I know the group head of ICT Engineering (Information and Communications Technology) has had a talk with the local Marvell rep on getting an NDA signed. I'll have a talk with him at the open day on the 3rd and see if we can get this sped up. Unfortunately a lot of companies here shutdown for summer holidays until the end of janurary , so we'll have to see what we can do. (summer school holidays 13 dec - 3rd feb) (uni holidays end of nov - march - full three months for students) I'm an interested in having a go but can not commit to any deadlines as am working full time for a research lab/company until the end of January on license plate recognition systems and deployments. May be better placed to assist with testing of a driver as we have a full communications testing lab which is not currently being utilised. Have equipment for up to 50GHz. Has anyone started looking at repeaters or message box storage or internet gateways yet ? Alex Gibson Technical Officer Network Sensor Technologies Laboratory University of Technology Sydney |
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: December 31, 2006
From: Mitch Bradley <wmb@xxxxxxxxxxxxx>
Request for comments. This patch creates a virtual filesystem that represents an Open Firmware device tree. It has been tested on an OLPC x86 system, but the code is not processor-specific (apart from its current location under arch/i386). It requires an Open Firmware implementation that can stay resident during Linux startup. It is similar in some respect to fs/proc/proc_devtree.c , but does not use procfs, nor does it require an intermediate layer of code to create a flattened representation of the device tree. The patch applies cleanly against the current version of git://dev.laptop.org/olpc-2.6 . (commit 5b9429be6056864b938ff6f39e5df3cecbbfcf4b). Please cc me (Mi