[EMAIL PROTECTED] (Dmitry V. Zhulanov) writes:
> > Files that are automatically generated, or which come with automake,
> > are often *not* checked into cvs. mig uses automake, right? Then use
> > automake -a to install the missing files.
> Should configure script do that, or INSTALL should
[EMAIL PROTECTED] (Dmitry V. Zhulanov) writes:
> Bulding cvs snapshot of mig from savannah.gnu.org fails. The
> problem is absense of depcomp script in $(MIG)/ directory.
Files that are automatically generated, or which come with automake,
are often *not* checked into cvs. mig uses au
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Being able to run make and skip the generation of some `unimportant'
> part, like man-pages (thats how it is used in coreutils for example).
To do that, I think I'd put something like this in Makefile.am,
MANTARGET = @MANTARGET@
man-pages:
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Well, the real problem is that the current configure ignores the
> problem completly. Would you be happy with changing the behaviour so
> that configure will print a warning if the program is missing,
Right, configure should definitely display a c
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Could you also fix the mig check so that configure will barf it it
> cannot find it?
Having configure barf for such things can be really annoying. It's
nice to be able to check out the code and do things like autoreconf &&
./configure && make doc,
James Buchanan <[EMAIL PROTECTED]> writes:
> This requires that glibc always does a secure lookup, and then inspects
> the node to decide if it wants to resolve the translator or not. This
> adds a small cost to all cross-translator lookups, but cross-translator
> lookups are expensive already an
"Roberto Reale" <[EMAIL PROTECTED]> writes:
> E.g., some servers very often panic or report ENOMEM when carrying
> out a request would cause them to exceed their allocable storage.
> Much better solutions can be devised: a server, for example, might
> keep a small reserve of memory (as Emacs doe
Trek <[EMAIL PROTECTED]> writes:
> It is normal that my LD_LIBRARY_PATH is not used when setting
> translators?
I believe it works like this: When a (passive) translator is started, it
inherits environment variables from its parent process, just like any
other process. The parent process is the f
Marco Gerards <[EMAIL PROTECTED]> writes:
> The thing that bothered me when reading these patches was that byte
> offsets were used quite often. This will make it not possible to use
> partitions bigger than 4GB in some circumstances.
Can't you use byte offsets, and 64-bit variables? I means, th
"Gregg C Levine" <[EMAIL PROTECTED]> writes:
> What is, the L4?
It's a modern micro kernel developed at the Technical University of
Karlsruhe, and perhaps at some other places. It's small (meaning that
a lot of stuff that is done by Mach has to be done in user space), and
aimed for good performac
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Is there a reference of what all the crt files are supposed todo? If
> not, could someone tell me what they do?
crt*.o and similar files are startup code. I.e. code that is linked
automatically into the binaries when you link C programs, and is
ex
Marco Gerards <[EMAIL PROTECTED]> writes:
> For better VGA support I want to add some features. First I'd like to
> add modeline support. This is how SVGATextMode, Xfree, svgalib,
> etc. setup a videomode. This is really easy to do, actually I already
> have most code to configure the hardware.
I
Jeroen Dekkers <[EMAIL PROTECTED]> writes:
> Of course the getopt interface uses some global variables: opterr,
> optopt, optind and optarg.
There's also one static variable in the getopt implementation:
/* The next char to be scanned in the option-element
in which the last option charact
Roland McGrath <[EMAIL PROTECTED]> writes:
> Right. But the theory (mine anyway) is that it is only libc, hurd,
> and maybe a couple of other special cases that need to think about
> this level of things. We can consider them individually once we
> agree that they are special cases. (The other one
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Should we be reporting the microkernel in the GNU triple?
>
> I think we would prefer not to.
Then how should glibc be configured when built for Hurd on L4? glibc
needs to know if it should use l4 or mach sysdeps, right? Let's also
assume it's cross
Robert Millan <[EMAIL PROTECTED]> writes:
> note what the docs say in reference to `char sun_path[108]':
>
> *Incomplete:* Why is 108 a magic number? RMS suggests making
> this a zero-length array and tweaking the following example
> to use `alloca' to allocate an
Robert Millan <[EMAIL PROTECTED]> writes:
> the following code seems to be compliant with the Glibc documentation
> referred to sockaddr_un, as it provides a char* as the second component
> of the struct:
Where do you find the char *? A sockaddr_un contains the family
identifier followed by the f
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Peter has already written device drivers for embedded Linux, and actually
> has a lot of experience on how to write device drivers portably (he is
> actually giving a talk at FOSDEM about it, he announced this on this list).
That's fine. Hurd require
Robert Millan <[EMAIL PROTECTED]> writes:
> glad to hear. do you think it's pointful to implement it in Mach so we
> can use interrupts instead of polling from now on?
I haven't looked at all at Mach interrupt handling. If it's easy to
implement intwait (did I understand you correctly that intwai
Robert Millan <[EMAIL PROTECTED]> writes:
> well, from my tiny experience on writing a parallel port driver i can say
> that userspace drivers for GNU are very portable. The only system resources
> one needs (besides Hurd's fs libraries of course) is a working ioperm(), which
> is a portable funct
"Frank Saar" <[EMAIL PROTECTED]> writes:
> 1. Is there anything like events ?
> I wonder how to implement an event mechanism without using volatile
> variables and continous testing of those with while();
I'm not sure I understand the question. Exactly what are you trying to
do?
Between proc
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Roland McGrath <[EMAIL PROTECTED]> writes:
>
> > That's insane. The interfaces on 64-bit machines use 64-bit sizes.
>
> This breaks network transparency, and is a bug in the MK8x versions of
> the kernel, that had to be fixed in the NORMA vers
Michal 'hramrach' Suchanek <[EMAIL PROTECTED]> writes:
> static void
> entry_point (void *(*start_routine)(void *), void *arg)
> {
> + assert (uselocale (LC_GLOBAL_LOCALE) == 0);
>pthread_exit (start_routine (arg));
> }
That's a misuse of assert. You should never depend on sideeffects in
Hisham Kotry <[EMAIL PROTECTED]> writes:
> With two in-dependent ip-stacks you'll probably need
> to do more work on the socket interface, as each would
> act on every call to any function of the socket API.
> Besides, a stack started after another wouldn't know
> about the currently exsisting con
Michal 'hramrach' Suchanek <[EMAIL PROTECTED]> writes:
> I think you completely misunderstood my post as your comments seem to be
> shifted by one layer. Or I misunderstood the pictures in prevois post.
Sorry for the confusion. Our termonology is far from perfect.
> As I understansd the picture
Michal 'hramrach' Suchanek <[EMAIL PROTECTED]> writes:
> At the level where ip address is registered ip port can be registered as well.
> The ip header has to be analyzed to determine ip address and that makes it
> easy to check the port at the same time.
Perhaps I should read the ip specs again,
Michal 'hramrach' Suchanek <[EMAIL PROTECTED]> writes:
> On Wed, Nov 06, 2002 at 02:52:25PM +0100, Niels M?ller wrote:
> > Olivier P?ningault <[EMAIL PROTECTED]> writes:
> >
> > > You didn't understand correctly. Layer 2 translator performs ethernet +
> > > arp, not ip !
> If you do not do IP int
Roland McGrath <[EMAIL PROTECTED]> writes:
> I don't think those are very usefu.
I guess your point is that it doesn't matter if the nfs-client
translator crashes (resulting in EGRATIOUS to the caller?) or returns
some other error when it runs out of memory. If it's a passive
translator, it will
Hi again. Now I've read your description twice, and there are still a
few things that I find are unclear, and there are also a few things
that I think I understand, and which I believe are wrong.
Olivier Péningault <[EMAIL PROTECTED]> writes:
> You didn't understand correctly. Layer 2 translator
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> "Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>
> > Is it intentional that unlink() on GNU/Hurd does not handle
> > directories?
>
> Yes.
How will this work for nodes that are both directories and files?
/Niels
_
Robert Millan <[EMAIL PROTECTED]> writes:
> # rm -r foo
> # rm -r foobar/
> # rm: cannot remove `foobar/': Invalid argument
>
> in what way is this problem suposed to be fixed? will
> trailing slashes be supported by the Hurd eventualy?
IIRC correctly, POSIX requires that "foobar" and "foobar/"
[EMAIL PROTECTED] (Neal H. Walfield) writes:
> The client would make a container containing the pages and give the
> server access to the container. Then the server would map the pages
> in the container, build a packet and send it down the network. Upon
> return, the client could reject the ser
Farid Hajji <[EMAIL PROTECTED]> writes:
> As far as Hurd/L4 is concerned, mono-directional ports
> are the only possible alternative.
And for high performance, I suspect the right way to do it is to share
some buffer space (preferably shared all the way down to the
network card), and send a messa
Olivier Péningault <[EMAIL PROTECTED]> writes:
> The network stack will be divided in several translators :
> - layer 2 translators. One of each will run per real physical device. It
> will give an interface for the layer 3 protocols, it will hide _all_ the
> data link stuff to upper layers. It wi
Olivier Péningault <[EMAIL PROTECTED]> writes:
> I don't know where you saw this use of IPv6 address that automagically
> include IPv4 addresses.
I'm talking about the "IPv4-mapped IPv6 address", as defined in section 2.5.4 in
RFC 2373 (you've found it already).
The hack to let an ipv6 socket ac
Olivier Péningault <[EMAIL PROTECTED]> writes:
> le sam 26-10-2002 à 20:13, Niels Möller a écrit :
> > like, it could be the current pfinet interface (where is that defined?
> in /hurd/socket.defs
Thanks. There's one thing I don't understand: What's an "a
I've tried to ponder on what the interfaces to the layer2 and layer3
code should look like. I'm thinking primarily of ipv4 and ipv6 over
ethernet, but I hope it's not too difficult to generalize to other
media.
Summary
~~~
I propose splitting the code into the following parts: layer 2 (device
Olivier Péningault <[EMAIL PROTECTED]> writes:
> le ven 25-10-2002 à 10:25, Niels Möller a écrit :
> > Sure, but do you really want them to run fully separately? It's common
> > (although not required by any standard, afaik), that an ipv6 socket
> > bound to the i
Olivier Péningault <[EMAIL PROTECTED]> writes:
> le jeu 24-10-2002 à 21:49, Niels Möller a écrit :
> ipv4 and ipv6 can run separatly.
Sure, but do you really want them to run fully separately? It's common
(although not required by any standard, afaik), that an ipv6 socket
Olivier Péningault <[EMAIL PROTECTED]> writes:
> - A translator per physical device, wich will present the upper side of
> a layer 2 protocol (ex: ethernet protocol over an ethernet card, ppp
> over a serial port, ...)
I think this is the right way, no matter how the servers above this
are design
Olivier Péningault <[EMAIL PROTECTED]> writes:
>le mer 23-10-2002 à 23:33, Niels Möller a écrit :
>> But that's all I've seen. So is anybody actually working on a hurdish
>> networking stack? I've seen no signs of that.
> If nobody works on it, I am
Vicente Hernando Ara <[EMAIL PROTECTED]> writes:
> * This last is an error I get in exec.c file.
> static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
> This trigger an error when compiling:
>exec.c:1382: initializer element is not constant
>
> however:
> pthread_mutex_t lock = PTHR
Everton Hermann <[EMAIL PROTECTED]> writes:
> This weekend I have ran my first version of SFTPFS,
Cool.
> and some functions from libssh to make the comunication
> between the translator and the sftp server.
The sftp protocol is quite independent from ssh (unless you do the ssh
transport and
Thomas Sippel - Dau <[EMAIL PROTECTED]> writes:
> So, without flaming, what exactly is /libexec useful for ?
`libexecdir'
The directory for installing executable programs to be run by
other programs rather than by users. This directory should
normally be `/usr/local/libexec', but
Bryan Wagstaff <[EMAIL PROTECTED]> writes:
> >[EMAIL PROTECTED] (Niels Möller) writes:
> >
> >> By the way, do you think there's any chance to change the semantics
> of
> >> open and write? I'd like the default behaviour to be as follows:
> >
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> At this point, it seems like the filesystem already supports
> everything we need, but we need a set of conventions about how to use
> it, so that programs like rm don't actually issue dir_unlink calls,
> but do something more clever.
I hope you
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Or, another possibility: that the place
> to implement it depends on the exact semantics?
Could be. I think it would make sense to start by outlining the
filesystem interface (rpc:s for listing old versions/deleted files,
opening or recovering an ol
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I wonder, should undeletion (aka the Windows trash can) better be done at a
> per-filesystem level (like, in diskfs), or with an extra-filesystem that is
> stacked (like shadowfs)?
I think I'd rather have a versioning filesystem (what emacs emulates
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
[I'm quoting this list for reference ]
> > A1. Chop the unicode stream up into graphemes.
> > A2. Convert each grapheme into the local encoding, resulting in one or
> > more bytes each. (I think you can do this with iconv).
> > A3. Pass each graph
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> What happens if I log into the Hurd machine remotely, from an UTF-8
> capable terminal (either hooked on a serial line or via telnet/ssh)?
> Doesn't the term need to be multibyte aware then just as well?
If anybody has a clear picture of the involve
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I have no idea what you are talking about. It seems to be related to the
> thread, but you have to be much more precise. What is this Unicode support
> you are talking about, that my second half seems to be missing?
Sorry. I'll try again...
I was
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Nobody will use UTF-32 as their local encoding for the foreseeable
> future, right?
I really don't know. Right now, utf8 seeems almost as impractical as
utf-32 to me, and I don't know how that will change when more programs
pick up support for large
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > For the multibyte issue, console already knows all about the characters.
> > So it can naturally dtrt if the term functionality is built in via
> > libtermserver. That seems like the righter thing.
>
> The console does not know about single chara
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> (well, ports_manage_multithreaded is still necessary, as Mach
> doesn't let you receive messages in the order they were sent easily)
Huh, that sounds hairy and suboptimal. For instance, I'd expect that
if a thread of mine sends some asyncronous and
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Another way to improve the situation is to make reception
> of update notifications and the actual screen updates asynchronous in
> the client, too. This requires a bit more logic, but adds flexibility
> in that the client can notice if a lot of out
Roland McGrath <[EMAIL PROTECTED]> writes:
> It would be helpful to see all the output rpctrace gives when it is lousing
> things up.
Here it is. I got it using some cut'n'paste via emacs and xterm, hope
it isn't too screwed up. Strings like "^?ELF^A^A^A" in the output
were actual control charac
This is a complete test program for the rpctrace problem.
8<
#include
#include
#include
#include
#include
int
main(int argc, char **argv)
{
if (access("/bin/ls", X_OK) < 0)
{
printf("/bin/ls not executable, according to access: %s\n",
strerror(errno));
Ok, now I've tried some more, using rpctrace.
But I think I have a new problem. The program behaves differently when
run under rpctrace than on it's own. The code contains a loop
for (i = *index; system_sources[i].path; )
{
if (access(system_sources[i].path, X_OK) < 0)
{
[ Changing list to bug-hurd ]
Jeff Bailey <[EMAIL PROTECTED]> writes:
> I wonder what's the Right Way to handle that there could be
> competing IP stacks on the Hurd (potentially tuned for slightly
> different things).
Interesting question. One obvious answer is to let different ip-stacks
use d
[EMAIL PROTECTED] (Neal H. Walfield) writes:
> > I'd *really* want to see a flag to mmap that means "If the file
> > shrinks, just map in some zero pages instead. Don't ever SEGFAULT me
> > about it".
>
> You could just set up a preemptor to catch these type of faults. This
> is what the file s
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> This is a bit related to changing the size of the file, which we probably
> should never do if the client mmap's it.
I'd *really* want to see a flag to mmap that means "If the file
shrinks, just map in some zero pages instead. Don't ever SEGFAULT me
Roland McGrath <[EMAIL PROTECTED]> writes:
> It just seems like the interface is wrongheaded if it winds up doing byte
> order conversions back and forth on the same machine.
I suspect that the conversions are actually not between UCS-4 little
endian and UCS-4 big endian, but between UCS-4 (some
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I don't know STREAMS, but having all these little servers stacked makes me
> think of performance :)
At least this is a case where the hardware seems to evolve faster than
the typing speed of the typical human...
> I am more interested in learning
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Mmmh. Interesting thought. I will ponder it, but the usefulness is not
> very high, considering that there is usually term between you and the
> console anyway. Or term would have to support it to.
Ooops, the term server is in the way as well. I
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Sun, Jun 02, 2002 at 03:00:15PM +0200, Niels Möller wrote:
> > Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> >
> > > VISUAL DISPLAY I \ /
> > > VISUAL DISPLAY II |
James Morrison <[EMAIL PROTECTED]> writes:
> I think there needs to be a new function ps_cmp_size_t. But it would look
> exactly like ps_cmp_float and ps_cmp_int. The easiest way I can see to do
> this is a macro
>
> #define COMPARE (type) ps_cmp_type ...
>
> Will this work?
I'm not sure y
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> VISUAL DISPLAY I \ /
> VISUAL DISPLAY II | | TERM ON VIRTUAl CONSOLE I
> ... > CONSOLE SERVER < TERM ON VIRTUAL CONSOLE II
> INPUT DEVICE I | | ...
> INPUT DEVICE II|
I've experienced a few more or less reproducible hangs on Neal's Hurd
box (dryden).
One example: I telnet in to the box. Start screen. Start emacs. Type
M-x man RET non-existing-command RET.
Then emacs displays a message saying that the man page can't be found,
and then I lose contact with both
Martin Gasbichler <[EMAIL PROTECTED]> writes:
> Why didn't you try the current version (0.6.2) of scsh? It's avaiable
> from http://www.scsh.net/download.html and contains a lot more
> features than 0.5.3.
I didn't know about it. I followed my old notes which said that
the place to look for scsh
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > This is an ugly hack, but I haven't figured out how to fix
> > scm_readlink properly.
>
> The GLibC manual has an example code that does loop properly over readlink
> while the returned name is as large as the buffer (and thus could be
> trunc
, hip, lop)\
((*(hip) = ((mask) >> 24) & 0xff),\
(*(lop) = ((mask) & 0xff)))
After these steps, both make and make check succeeded.
Happy hacking,
/Niels Möller
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Ognyan Kulev <[EMAIL PROTECTED]> writes:
> Kilobug wrote:
> > Hum, how should I write my name, so ? Should I mispell it ?
>
> Germans use `ae' and `ue' (or `ea' and `eu'--I can't recall exactly)
> for their umlauts. Isn't there something like that in french?
I don't know about French, but for
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Right, but that's already a Hurd-specific extension. So it's fine to
> expect it to use another Hurd-specific extension to get a reliable PID
> or other identification.
What would such an extension look like?
/Niels
__
Roland McGrath <[EMAIL PROTECTED]> writes:
> We do. The virtual copying behavior is enabled by a Boolean argument to
> vm_map. The issue is having several mappings together as an atomic unit
> relative to intervening write calls (or modifications via shared
> mmap).
One could get the (suckish)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> [EMAIL PROTECTED] (Niels Möller) writes:
>
> > I guess I should have asked for the ratio B/A. If that's small, as you
> > claim, there should be a significant gain. _If_ it turned out that A
> > and B were of the s
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I'm quite sure it would help a lot.
Ok, that's good to know.
> Number (A) is quite large. Number (B), which is the case you asked
> about, is quite small.
I guess I should have asked for the ratio B/A. If that's small, as you
claim, there sho
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> [EMAIL PROTECTED] (Niels Möller) writes:
>
> > Does anybody have any idea how often this case occurs with typical
> > activities like compilation?
>
> What's the point of the question: to decide if we can ignore
The talk about child hurds and faking devices has brought a question to
my mind, which I hope you can shed some light on.
We do need some abstraction that represents control over the hardware.
Like the Mach master device port. If you have a send right to that,
you can do whatever you like with th
Thanks for the explanation. I'm trying to understand what consequences
for performance can be expected.
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> There are cases (as noted before) where the following sequence arises:
>
> write block A
> write block B
> write block A again
>
> and wher
Moritz Schulte <[EMAIL PROTECTED]> writes:
> I haven't found a way in the FTP protocol, which helps us here.
In theory, the command "mlst" should help. But it's also
underspecified and not always implemented. For example, ftp.roxen.com
implements it like this:
$ ftp ftp.roxen.com
Connected
Damien Genet <[EMAIL PROTECTED]> writes:
> or don't use automake, whereas parted use automake (really ugly)
You don't have to use libtool just because you use automake (just as
you don't have to use automake just because you use autoconf).
Put the rules for building the shared library into Make
[EMAIL PROTECTED] (Alfred M. Szmidt) writes:
> And here I go again. This time it's a whole new program, that will
> allow you to change the st_author field on GNU/Hurd.
Just one comment, on the Makefile:
> --- fileutils-4.1.7.orig/src/Makefile.am Sun Feb 17 12:00:25 2002
> +++ fileutils-4
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Sat, Mar 30, 2002 at 09:36:44AM -0700, Jon Arney wrote:
> > This probably belongs on bug-oskit
>
> If the fix is correct (from your description it seems so, but I am no oskit
> hacker), this indeed should be reported on the oskit devel list and t
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
What's the definition of mach_msg_type_t? I have the Hurd sources, but
not Mach sources, around.
> On Sun, Mar 31, 2002 at 01:59:56AM +0100, Marcus Brinkmann wrote:
> > ok, here is some hard data. It turns out that the comparison:
> >*(int *) &ms
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> So on the Hurd, you had 30%, and on Linux, you have 60%?
Sorry, it seems I was too careless when reading Ludovic Courtès'
message, I read "most of the cpu time" but missed the parenthesis
saying "30 %".
But anyway, for a performance compariso
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> [EMAIL PROTECTED] (Niels Möller) writes:
>
> > Perhaps idling, waiting for disk i/o requests to complete?
>
> Do a big tar extraction on Linux and note that your tar process soaks
> up plenty of CPU time.
The number
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Ludovic Courtès <[EMAIL PROTECTED]> writes:
>
> > This kind of observation is quite normal I guess, due to the extensive use of
> > RPCs and so on, but are there still some optimizations that could be
> > implemented in order to reduce CPU consu
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I have a more concrete idea about how to change diskfs into an
> "ordered writes" instead of a "synchronous writes" model. If someone
> prods me, I can explain it.
Please do.
Regards,
/Niels
___
Bug
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Well, if this is possible we could just avoid syncing the blocks back to the
> store in the filesystem in the first place. Thomas' point is exactly that
> to make the expected guarantees you can not cache the writes in any
> simplistic fashion: You
Jon Arney <[EMAIL PROTECTED]> writes:
> For instance, a simple LRU cache algorithm implemented in
> 'libstore' might provide a large performance advantage with
> the caveat that it might occasionally lead to disk inconsistencies.
The important thing for this problem is to cache writes, I think.
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> It must guarantee that the directory is updated to drop the link
> *before* the inode refcnt is decremented and the inode possibly
> cleared.
>
> So it synchronously writes the directory, and then lets the inode get
> cleared on the next regular
Jon Arney <[EMAIL PROTECTED]> writes:
> Another good idea. Forgive my simple-minded-ness, but a simple
> approach to the problem might be for filesystems to voluntarily
> register themselves by simply writing to /etc/mtab as a real
> file. Is this a job that really needs a translator to do?
> W
Jon Arney <[EMAIL PROTECTED]> writes:
> One question I had was about your list of planned changes. On there,
> you list "Posix shared memory". Is anybody working on this?
Somebody did some work on it a while ago. I don't remember the
details, but there were some discussion on the lists (it sho
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I'm baffled. If it's a plain pipe, then you simply close the end
> you're writing on, and the reader gets EOF.
Well, I think there are systems where pipe gives you a bidirectional
pipe, but where shutdown on the pipe gives you the ENOTSOCK erro
Roland McGrath <[EMAIL PROTECTED]> writes:
> Saying "bidirectional pipe" is descriptive too. :-) They're the same thing.
> As we discussed in great detail here at the time, `pipe' now creates a
> bidirectional pipe, i.e. it creates a socketpair and does not call
> shutdown.
You ought to set some
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Now, suppose you have a program like wc that collects data and returns
> a summary of that data. It will read from stdin until it gets EOF, and
> then print from stdout. But if I use the above translator, I have only
> one filedescriptor, and I can
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> You want the "shutdown" call, which should do the right thing.
Does shutdown work on plain pipes, or is it it necessary to use
socketpair instead of pipe? (Not that that is usually a problem, I'd
recommend socketpair everytime, except if one act
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Do I add or remove confusion if I say that the console server should support
> both models? The generic part of the console server would then always pass
> through without interpretation, the device specific part can either pass it
> on further to t
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> This scheme already exists, but at the application level. It is
> called terminfo(5) and works very well. I think it would be a
> mistake to reimplement it, just poorer.
For the traditional serial console device, what happens is that the
application
Neal H Walfield <[EMAIL PROTECTED]> writes:
> > I changed it to treat an argument of just "HOST" like "HOST:/". It would
> > be good to support URL syntax too, though that should dtrt with a :PORT.
>
> This syntax may make using ipv6 addresses difficult.
I'm not sure which of the `:':s above y
1 - 100 of 147 matches
Mail list logo
