On Fri, Aug 28, 2009 at 2:37 AM, olafbuddenha...@gmx.net 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
entreated Gianluca to check what
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
On Mon, Aug 24, 2009 at 9:20 AM, Sergiu
Ivanovunlimitedscol...@gmail.com 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
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
On Sun, Aug 23, 2009 at 11:07 PM, Sergiu
Ivanovunlimitedscol...@gmail.com 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
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
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 PCMCIA
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
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,
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 need
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 Xen port
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 affect
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//Makefile.in2006-02-20 22:17
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 Gianluca Guida [EMAIL PROTECTED
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 today
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
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
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 versions on
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,
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/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
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 setted
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 you
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,
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 quite an
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 bug or
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
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 (it
happens in some motherboard).
diff -ru
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
variables
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
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 systems.
Wow,
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
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, vm_page_queue_free_normal): New
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
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
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
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
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,
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
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 each #if
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 =
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/GNUMachRevivalProject
I
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 the
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.
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 hurd
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 completely
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/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:
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 sent
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 the
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 fine
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
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
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
help?
Of course the easy
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
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
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/rtl8139.c: Added support for
DLink
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/rtl8139.c: Added support for
DLink 528 TX and DLink 538
61 matches
Mail list logo
