On Fri, Aug 28, 2009 at 3:22 AM, wrote:
> On Sun, Aug 23, 2009 at 10:42:41PM +0200, Gianluca Guida wrote:
>
>> At the time, I was actually in favor of a separate stowfs which were
>> just using common code for unionfs, but politics and other rather
>> meaningless reasons
On Fri, Aug 28, 2009 at 2:37 AM, wrote:
> On Wed, Aug 26, 2009 at 01:07:27AM +0200, Gianluca Guida wrote:
>> > This is a non-trivial problem. Other unionfs implementations
>> > probably spent considerable time figuring out how to do it best. I
>> > entreat
Hm, funny things happens while grepping past mail.
> This is a non-trivial problem. Other unionfs implementations probably
> spent considerable time figuring out how to do it best. I entreated
> Gianluca to check what over implementations do, instead of trying to
> reinvent the wheel -- but he wou
On Mon, Aug 24, 2009 at 9:20 AM, Sergiu
Ivanov wrote:
> Oh, sorry, I should have asked *you* in the first place :-( Please,
> forgive my absent-mindedness :-(
Nah, it's OK. Thomas and antrik are the right guys to ask in general,
since they're following your work and the Hurd much more than I do.
On Sun, Aug 23, 2009 at 11:07 PM, Sergiu
Ivanov wrote:
> I see... It has never occurred to me that unionfs could be used in a
> packaging system :-)
There are things you don't really want to know about the Hurd. :-)
> I wonder whether there is still the necessity to keep things as they
> are. I
Hi Sergiu,
I do agree that it's counter-intuitive. Please note that the stow
functionality was mostly meant for the GNU system as a base for a --
rather complex I'd say -- packaging system.
The idea was that the first level after the stow directory was the
package, and we were matching against pa
On Nov 10, 2006, at 12:36 AM, Thomas Schwinge wrote:
Hello.
On Thu, Nov 09, 2006 at 02:06:45PM -0300, Leonardo Pereira wrote:
"I may disagree with what you have to say, but I shall defend, to the
death, your right to say it." - Voltaire
[...]
So, Leonardo, with forwarding his email, you es
Hi there,
On 8/27/06, Stefan Siegl <[EMAIL PROTECTED]> wrote:
The patch along adds yet another configure option (enable-pcmcia-isa),
allowing to compile that bits in. The latter is especially useful if
your PCMCIA bridge, attached to the PCI bus, doesn't get an IRQ itself.
In this case the PCMCI
Hey Thomas,
On 6/8/06, Thomas Schwinge <[EMAIL PROTECTED]> wrote:
somewhere for a weekend or similar. Somewhere will be determined
somewhen and somewhen will be determined by someone etc. (And I remember
that Gianluca invited us to Italy a few times, so... :-)
Yes, that's true. The only pr
Follow-up Comment #4, patch #4818 (project hurd):
Hey Thomas, thanks for the followup.
I'll try to find some time to investigate this, doesn't seem to me such a
complicated issue tho. Anyways, I already have a faster substitute code for
the bitscanning stuff (which was legacy code).
Thanks,
Gia
On 4/23/06, Jeroen Dekkers <[EMAIL PROTECTED]> wrote:
> To me it looks like that common standard isn't going to be here
> anytime soon.
I didn't said that it would have been a short term thing. But
anyways, we should closely follow what's going to happen in the linux
kernel, since that would affe
Hi there (again)!
On 4/20/06, Ognyan Kulev <[EMAIL PROTECTED]> wrote:
> Thomas Schwinge wrote:
> > Possible projects I thought about submitting include `libchannel',
> > `pfinet rewrite', `nfs / nfsd rewrite / enhancement', `GNU Mach on Xen'.
>
> It will not be surprise to anyone that I consider X
Hi,
I am finally back writing some serious mails.
On 4/20/06, Thomas Schwinge <[EMAIL PROTECTED]> wrote:
> I could imagine handling the task of mentoring with the help of the whole
> Hurd community. That is, I'd be the official mentor for the projects
> we're going to submit. But for sure I'll
Don't want to disturb your flames guys, but here's another cute quote:
"I claim that Mach people (and apparently FreeBSD) are incompetent
idiots. Playing games with VM is bad. memory copies are _also_ bad,
but quite frankly, memory copies often have _less_ downside than VM
games, and bigger caches
Hi,
It's almost only aesthetic but Makefile.in 's variable topfiles lacks
Makerules.in entry. This creates problems with 'make dist'.
2006-03-03 Gianluca Guida <[EMAIL PROTECTED]>
* Makefile.in (topfiles): Add 'Makerules.in'.
--- vanilla/gnumach/
On 3/3/06, Gianluca Guida <[EMAIL PROTECTED]> wrote:
> What exactly is memory_object_reply.cli doing in the device/
> directory? Wouldn't be more appropriate for it to stay in the vm/
> directory?
memory_object_reply.cli is a misleading name. What actually is is the
user v
On 3/4/06, Thomas Schwinge <[EMAIL PROTECTED]> wrote:
> Are there any objections against removing the currently unused and
> apparently broken NORMA code from GNU Mach? (Currently `#if'ed out, see
> `bogus/norma_*.h'.)
Uh.. ehr... I know that it's code gone beyond all hope but... I was
right toda
u want, I can provide you a tarball of the
tree I built.
Thanks,
Gianluca
2006-02-24 GIanluca Guida <[EMAIL PROTECTED]>
* device/blkio.c: Moved to ...
* legacy/blkio.c: ... here.
* device/chario.c: Moved to ...
* legacy/chario.c: ... here.
* devi
Hello,
What exactly is memory_object_reply.cli doing in the device/
directory? Wouldn't be more appropriate for it to stay in the vm/
directory?
Here's a simple changelog in case the answers to my questions are
respectively "No Idea." and "Yes.".
2006-03-03 Gia
Hi Manuel,
On 2/24/06, Manuel Menal <[EMAIL PROTECTED]> wrote:
> I'll be working on those patches, and BPF as well, during the next week,
> so they might change.
Great!
promisc.patch is very well done, and shows exactly what I tried to
explain with my broken english to Richard. :-)
Support for
Hi,
There's no a solution still, but it should be quite easy to find one.
The problem is that the Mach's glue doesn't handle at the moment the
multicast functionality.
Your solution should be then to hack the both Mach's device interface
and it's linux emulation glue to use advanced device functio
Hi,
On 2/15/06, Thomas Schwinge <[EMAIL PROTECTED]> wrote:
> I can however deduce the need for a file in the top-level directory
> containing something like ``If you want to work on the Mach kernel's core
> or system dependent parts or ..., be sure to reset your CVS checkout to
> the revision `gnu
Hello,
On 2/8/06, Thomas Schwinge <[EMAIL PROTECTED]> wrote:
> > Wouldn't it be better to
> > simply make the native drivers work?
>
> Are you interested in reviving and maintaining e.g. NIC device drivers
> that got crudely fit into Mach more than fifteen years ago, based on
> _really_ old versio
Hi.
On 2/5/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote:
> StowFS doesn't create links, it uses unionfs. The difference of both is
> almost simple, since with links you can remove stow and everything will keep
> working. With StowFS you need to have stowfs running to get things working
> (this "
Hi,
On 2/5/06, Filip Brcic <[EMAIL PROTECTED]> wrote:
> How about a daemon (or service, or translator, or whatever) that would monitor
> the "/Programs" directory where the new programs are installed. And when that
> daemon sees a new program it automagicaly does a "ln -s" for binaries,
> includes
On 2/3/06, Thomas Schwinge <[EMAIL PROTECTED]> wrote:
> I checked in the following:
>
> 2006-02-03 Thomas Schwinge <[EMAIL PROTECTED]>
>
> * Makerules.in: Add -fno-strict-aliasing to CFLAGS.
> * i386/linux/Makefile.in: Likewise for linux-gen-flags.
>
>
> Please confirm this is eno
Hi,
On 2/3/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote:
> Possibilities to make a stowfsed system booting:
I was referring to *your* nowstowfs booting stuff, not mine.
As already said previously on this thread, stowfs is implemented as a
set of unionfs running, so no stowfs.static thing may h
Hi,
On 2/3/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote:
> What you will need is, instead stowfs, that get package/bin and merge it on
> /bin, is a translator that gets package/bin and put it on PATH. The same is
> valid for /lib and /sbin (I know no variable to set "include" directories).
So
Hi,
(CCing to gnu-system-discuss)
On 2/2/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote:
> I was thinking about why we need to merge all packages on the root
> filesystem is this is not a requirement of POSIX. Posix uses PATH to
> determine where the executable files are, lib directories are sett
> P.S. Gianluca, it'd probably be a good time now to request and sign
> assignment papers for GNU Mach.
Hmph, I requested that for the Hurd and GNU Mach, but now that I look
at it, in the copyright assignment paper I signed one year ago only
GNU Hurd is mentioned.
Is that enough? At that time, mo
t.c).
This patch make the glue use Mach AST's and remove the invasive (IMHO)
SPL's hacks and let schedule() just block the thread, not making it
deal with software interrupts.
Testing and feedback, as always, would be gratly appreciated!
Thanks,
Gianluca
2006-02-01 Gianluca Guida &l
Hi,
well bug-hurd is not properly the right place to discuss this, but
I'll keep this discussion public in case someone is interested.
On 1/30/06, Matheus Morais <[EMAIL PROTECTED]> wrote:
> I'm a bit confuse about how mach revival project will work in some aspects.
The "Revival Project" is quit
Hey,
On 1/30/06, Matheus Morais <[EMAIL PROTECTED]> wrote:
> > Well, you sent me already the patches. As soon as I'll make a
> > repository/site or something for it, I'll put it as a first cleanup of
> > the code. That's what I can do as 'clean up subproject' volunteering
> > leader. If you -- for
Hi,
On 1/29/06, Marco Gerards <[EMAIL PROTECTED]> wrote:
> That is weird. I always thought that for compatibility reasons IRQs
> are always <16. In case the OS supports more than 16 IRQs, the OS can
> change the IRQs to prevent shared IRQs. With your NIC this is not the
> case, is this a BIOS b
01-20 Gianluca Guida <[EMAIL PROTECTED]>
* vm/pmap.h (pmap_is_dma, pmap_is_normal): New functions.
* vm/page.h (VM_PAGE_DMA): New macro.
(vm_page_queue_free): Variable removed.
(vm_page_queue_free_dma, vm_page_queue_free_normal): New
s that for such a small path using Savannah's Patch system is a
waste, right?
Regards,
Gianluca
2006-01-28 Gianluca Guida <[EMAIL PROTECTED]>
* linux/src/drivers/net/pci-scan.c (pci_drv_register): Skip device
if we are getting an invalid IRQ >= 16 and different from 255
Hello,
As you've noticed, I just sent to savannah the new patch, which is
basically the same but adds the last missing feature: the collecting
of the unused memory in case of need (by the pageout thread).
I think this patch is definitely reading for testing, so I would be
happy if someone would e
Hi,
On 1/25/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote:
> As I know, those interfaces already exists. So, I didn't understoo your "we
> shouldn't add such interfaces to Mach". I do not understand why someone
> would like to use IPC if we have an alternative that is faster than IPC.
> This is n
On 1/25/06, Marco Gerards <[EMAIL PROTECTED]> wrote:
> > Please note, though, that we obviously need to modify the hurd and/or
> > the libc to let the system use it.
>
> Can't it be implemented as another store class or so? In that case it
> can be used in the Hurd without affecting current system
Hi,
There are two piece of code which are giving me problems (I am looking
out for code cleaning in the device section).
These piece of code implements some possible speed up unused at the
moment. They are:
- device-write trap: it uses a specific syscall to write to device (as
opposed to IPC to
Hi,
Among lot of warning, while compiling GNU Mach with recent gcc's we
get lot of warnings related to strict aliasing optimization. This
might lead the compiler into producing incorrect code.
I personally think that instead of modifying GNU Mach's code (and
limit our cast usage) we can simply g
Hi,
On 1/22/06, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Obviously vm bugs are very painful to debug when they happen. Can you
> briefly describe what testing this patch has undergone? (How
> stressful a test, importantly?)
Yes, this is THE question.
Well, I started writing and testing
For inline patches fans, here it is:
This is a new version of the patch.
No major improvement, it's just a cleaning of the previous patch:
- Removed the rtl8139.c, which I forgot to remove in the previous patch;
- Removed some debugging printf that I forgot, in pure StoMach style;
Happy Testing
Follow-up Comment #1, patch #4818 (project hurd):
This is a new version of the patch.
No major improvement, it's just a cleaning of the previous patch:
- Removed the rtl8139.c, which I forgot to remove in the previous patch;
- Removed some debugging printf that I forgot, in pure StoMach style;
On 1/21/06, Alfred M. Szmidt <[EMAIL PROTECTED]> wrote:
> PS, I'm assuming that the inclusion of ../rtl8139.c was a mistake. ;)
Whops!
Yes it does, it's not even needed anymore, since some patch in the
debian (which I hope is going to be committed soon) already fixes
this!
Posting cleaned patch s
ould test
it.
Thanks for reading this,
Gianluca
2006-01-20 Gianluca Guida <[EMAIL PROTECTED]>
* vm/pmap.h (pmap_is_dma, pmap_is_normal): New functions.
* vm/page.h (VM_PAGE_DMA): New macro.
(vm_page_queue_free): Variable removed.
(vm_page_queue_free_dma,
Hi,
For people that doesn't like mails coming from savannah bug tracker
(this involves me too) I inline the patch.
It's quite long (1k lines) but well, just to give an idea of what it
does, here it is.
2006-01-20 Gianluca Guida <[EMAIL PROTECTED]>
* vm/pma
Hi,
On 1/16/06, Matheus Morais <[EMAIL PROTECTED]> wrote:
> There exist support to run wireless cards in Hurd? If no, its possible (with
> the currently workable system) design that kind of device driver to Hurd?
> Its already exists a lot of workable drivers in GNU/Linux and FreeBSD, its
> possib
Hi,
Adding more memory to kernel mapping is indeed a good idea (stomach
has a rough hack that does the same almost).
Just another bothering question:
On 1/9/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> - kernel_virtual_end = phys_last_addr + morevm;
> + kernel_virtual_end = phys_
Hey,
On 1/8/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> Agreed. Here is an updated patch
That's quite cool. Thanks.
Just another thing:
Index: device/io.c
===
RCS file: device/io.c
diff -N device/io.c
--- /dev/null 1 Jan 19
On 1/8/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> The problem is that when opening a device (device_open), the port that
> is returned to the user is &device->dev: see
> device/ds_routines.c:device_open():
Ok. The patch is functionally OK. Only thing I ask is that you add
some comment at eac
Looks ok to me.
My only 0.02 euro here is that since io_port_create and
io_port_destroy are both exported function, it would be nice to have
the device code (ioopen and ioclose) in a separate, architecture
independent file, since it is an architecture independent device.
G.
--
It was a type of p
On 1/8/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> I was not sure about this indeed. The caller here is actually all
> drivers that call io_port_create()...
What drivers and where?
Can you be more precise about it? The more I look at the patch the
less I understand what it is for.
Thanks,
On 1/8/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> Alfred M. Szmidt, le Sun 08 Jan 2006 17:57:27 +0100, a écrit :
> > Looks ok. Why the ifdef i386 though?
Because this patch assumes the i386 device emulation that Mach's i386
subsection uses. That is actually architecture independent, and for
Hi there,
On 12/20/05, Sergio Lopez <[EMAIL PROTECTED]> wrote:
> I've written a list of tasks that I think we need to improve in GNU
> Mach. If you find anything missing here, please feel free to add a entry
> with a short description.
>
> http://hurd.gnufans.org/bin/view/Mach/GNUMachRevivalProjec
On 12/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> To get an idea how hard fork() is for us, Gianluca did a simple test,
> on GNU/Hurd he got 312 forks/second, and on the same machine but in
> GNU/Linux, he got 8170 forks/second.
FYI, I just compiled and executed under linux and under hurd
On 8/28/05, Jose E. Marchesi <[EMAIL PROTECTED]> wrote:
>
> This is not a bad thing per se if you guys don't feel like working on
> Mach anymore, but it would probably be good to communicate this clearly
> to people either way, as some still seem to be interested in hacking on
> it
On 8/28/05, Jose E. Marchesi <[EMAIL PROTECTED]> wrote:
>
> This is not a bad thing per se if you guys don't feel like working on
> Mach anymore, but it would probably be good to communicate this clearly
> to people either way, as some still seem to be interested in hacking on
> it
Hey,
thanks for trying stomach out and for even getting a log.
On 8/26/05, Shakthi Kannan <[EMAIL PROTECTED]> wrote:
> I find the console response to be much faster than
> gnumach. Have you given lot of printfs during the boot
> code?
Faster? Hmm, perhaps there are just a lot of printfs and so
Hi Shakthi,
On 8/25/05, Shakthi Kannan <[EMAIL PROTECTED]> wrote:
> When I boot, all initializations take place (hdd, CD).
> It even probes for floppy, I don't have a floppy drive
> in the T41. It finally hangs at:
>
> (hd0,3)/hurd/ext2fs.static: device: hd0s4: No such
> device or address
>
> My
On 8/24/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > this
> > current thread can be marked as spam and forgotten without any serious
> > loss.
> I am sorry if that spamimg comment was ment to me.
No, hey, thanks for your post!
I just meant that if that was the problem, *my* mails were com
On 8/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> My card worked under GNU/Hurd. (Was able for exapmle to ping)
> Probably you have to configure your interface. The answer how to do it is
> probably here:
>
> http://web.walfield.org/pub/people/neal/papers/hurd-installation-guide/english/h
On 8/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I talk about network adapter which is present in linux and in HURD by
> documentation. And in Windows it easily can recognized. I gain not
> recall it's name. It is similar to rtl8139.
Can you check the name, please? Can you tell me the
On 8/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Probably that model is supported. (Also do not remeber the model name
> correctly, on linux the driver name was [EMAIL PROTECTED] with a quite similar
You're definitely talking about rtl8139.
Gianluca
P.S. (Sorry prikulis, I previously s
On 8/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> rtl8931 I don't remember number exectly. I can make a mistake. But in
> Linux there is a module rtl8931.o And when are drivers in Mach? In
> kernel itself? Not in modules?
not rtl8139?
If so, it might be that the PCI ID is not present in t
On 7/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Could anyone tell me how can I install mouse on hurd? I have USB mouse
> with 3 buttons. I can replace it with mouse on com1 port if it does
> not supported.
There's still no support for USB in GNU Mach and the Hurd. Using COM1
should be f
Hi all,
I've been recently working on GNU Mach 1 branch to port oskit drivers
and remove the linux glue.
THIS IS NOT ANOTHER OSKIT-MACH. It is different. Differently from
oskit-mach in this tree only the linux_dev component of oskit is used,
and it is added at linking time. Furthermore, in the so
Hello,
for those interested, the unionfs translator in hurdextras CVS at
savannah now has a rude writing support. It actually implements
{rm, mk}dir and file creation and unlinking.
I am sure there are still bugs, so testing is seriously appreciated.
Thanks,
Gianluca
--
It was a type of peopl
Hello
On 5/1/05, Gianluca Guida <[EMAIL PROTECTED]> wrote:
> I actually tried to made the same work for bold faces, but being the
> capability for real bold mode a GNU extension and not being an expert
> of terminfo, I don't know the capability code for it. Anybody can
>
Hi.
Emacs 21 in tty mode maps slanted faces to dimmed text, indipendently
from the terminal support for italic mode.
This patch maps -- if the terminal supports it -- slanted face to
italic fonts. With this patch, then, a properly configured Hurd
console can show italic fonts when in font-lock mo
Hi,
in gnumach non oskit branch there's a couple of file
named fpe.b and fpe.b_elf; They're essentially uuencoded
objects (ELF and non ELF) that implement FPE
emulation. I can't find source of them anywhere.
The elf version actually is uudecoded and linked.
Does this create a problem with gnu
I couldn't think it was so important stuff however:
At Thu, 05 Feb 2004 23:31:34 +0100,
Danilo Segan wrote:
>
> Gianluca Guida <[EMAIL PROTECTED]> writes:
> >
> > 2004-02-05 Gianluca Guida <[EMAIL PROTECTED]>
> >
> > * linux/src/drivers/net/rtl
At Thu, 5 Feb 2004 11:50:08 +0100 (MET),
Alfred M. Szmidt wrote:
>
>This is the patch, but I haven't tested it:
>
> ChangeLog please.
>
Here it is.
I tested it and works.
2004-02-05 Gianluca Guida <[EMAIL PROTECTED]>
* linux/src/drivers/net/rt
Hello,
Anthony Ventimiglia wrote a trivial patch, back in July 2002,
that added support in the gnumach-1x branch for Dlink DFE 538 TX
(and actually works even on DFE 528 TX). Since they are common
rtl8139 NIC (and I have many of them ;-) I think it would be a
good idea to apply it..
The mail
74 matches
Mail list logo
