Re: The Hurd: what is it?
>
> Note that some version of L4 consumed 4 TLB entries for one IPC: 2
> that were the same for every kernel interrupt. 1 for the source
> thread. 1 for the destination thread. It is hard to do better than
Using a bigger ('super') page the kernel interrupt stuff can be mapped
using only 1 TLB entry no ?
TLB entries are a fairly scarce resource in some of the smaller CPUs. A
lot of CPUs also use so called 'soft refill mechanism' meaning the OS is
responsible for managing the TLB. Obviously the TLB refill handler is
heavily optimized, but still you want to be able to map the complete working
set using TLB entries.
Cheers,
Peter (p2).
--
goa is a state of mind
signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Screensaver support for the Hurd console
Hi, > Hi, > > As some of you might remember, I sent in a patch for screensaver > support for the Hurd console. I am resurrecting that patch now. > > All work has mostly be done. At the moment my biggest doubt is how to > configure the screensaver support when starting the console client. I > have two ideas for that: > > First of all, a screensaver can be registered by any plugin. So the > `life' plugin registers the `life' screensaver, a screensaver that > shows conways game of life. There is a blank plugin that registers > the screensaver blank, which just clears the screen. The vga driver > will register 3 screensavers: vga_standby, vga_suspend and vga_off. > These correspond with the DPMS power levels. > > To configure the screensaver I could use this: > > console -d vga --dpms-standby=vga_standby --dpms-off=vga_off > --dpms-standby-timeout=400 --dpms-off-timeout=800 --saver-events=INPUT,BELL > /dev/vcs > > In that case the console will start blanking after 400 seconds using > the vga_off screensaver and the display will turn off after > (400+800=)1200 seconds using vga_off. It will stop when someone > presses a key or the bell is activated. > > Another way to configure this would be: > > console -d vga --screensaver="vga_standby=400,vga_off=800" > --saver-events=INPUT,BELL /dev/vcs > > Or even: > > console -d vga --screensaver="vga_standby,vga_off" > --saver-events=INPUT,BELL /dev/vcs > I think we need a message interface to the screensaver for configuration. This allows per user configuration. (ie. if another user logs in on the console, a program can be launched from her .bash_profile to reconfigure the screensaver to her personal settings). It also allows any fancy configuration scheme without impacting the console code at all. Cheers, Peter (p2). signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Chaos Congress 2003
Hi, Anyone going to the Chaos Congress in Berlin this year ? Cheers, Peter. signature.asc Description: Digital signature ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: SVGA console
Hi Marco,
On Wed, Aug 27, 2003 at 08:52:42PM +0200, Marco Gerards wrote:
> Hi,
>
> "Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes:
>
> > struct syncinfo {
> > enum { SPLIT_SYNC, CSYNC, SYNC_ON_COLOR } type;
> > union {
> > struct {
> > polarity hsync_pol;
> > polarity vsync_pol;
> > } split_sync;
> > struct {
> > polarity csync_pol;
> > } csync;
> > struct {
> > polarity pol;
> > enum {RED, GREEN, BLUE} color;
> > } sync_on_color;
> > } sync_parameters;
> > };
> >
> > typedef unsigned int display_flags;
> >
> > #define DISPLAY_FLAGS_LACE (1<<0)
> > #define DISPLAY_FLAGS_EXTSYNC (1<<1)
> > #define DISPLAY_FLAGS_DOUBLE(1<<2)
>
> Ah, thanks. I've updated the interfaces to use this. I've changed it a
> bit and added some comments, can you have a look at the new interfaces
> if this update was sane?
>
Ok.
> [...]
>
> > I wuould rather have :
> > error_t (*set_horiz_timings) (unsigned xres, unsigned left, unsigned
> > right, unsigned hslen);
> >
> > /* set number of visible horizontal pixels to xres,
> >set number of left margin pixels to left,
> >set number of right margin pixels to right,
> >set horizontal sync pulse width to hslen */
>
> Yes, that is much better. I will update the interfaces soon. I haven't
> done this because it requires that all modelines will be updated (yes,
> I'm lazy :)).
>
Ok. I guess fb.modes has all knowledge on how to do this.
> [...]
>
> > error_t (*set_syncinfo) (struct syncinfo *si);
> >
> > error_t (*get_syncinfo) (struct syncinfo *si);
> >
> > error_t (*set_options) (display_flags flags);
> >
> > error_t (*get_options) (display_flags *flags);
>
> I've added these too. Thanks.
>
> Thanks,
> Marco
>
>
> The new interfaces:
>
> /* video-driver.h - Video driver interfaces.
>Copyright (C) 2003 Free Software Foundation, Inc.
>Written by Marco Gerards.
>
>This file is part of the GNU Hurd.
>
>The GNU Hurd is free software; you can redistribute it and/or
>modify it under the terms of the GNU General Public License as
>published by the Free Software Foundation; either version 2, or (at
>your option) any later version.
>
>The GNU Hurd is distributed in the hope that it will be useful, but
>WITHOUT ANY WARRANTY; without even the implied warranty of
>MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>General Public License for more details.
>
>You should have received a copy of the GNU General Public License
>along with this program; if not, write to the Free Software
>Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA. */
>
> /* The powermodes that can be used to configure the power state of the
>monitor. */
>
> #ifndef _VIDEO_DRIVER_H_
> #define _VIDEO_DRIVER_H_ 1
>
> /* DPMS powermodes. */
> enum powermode
> {
> /* Normal operation. */
> PM_ON,
> PM_STANDBY,
> PM_SUSPEND,
> /* Turn the screen off. */
> PM_OFF
> };
>
> typedef enum powermode powermode_t;
>
> /* Use polarity to use for syncing. */
> typedef enum polarity
> {
> POLARITY_LOW,
> POLARITY_HIGH
> } polarity_t;
>
> /* The kind of sync signal that should be used. */
> typedef struct syncinfo
> {
I would change line(s) to signal(s). Seems a bit more clear to me.
> enum
> {
> /* The videocard use the HSYNC and VSYNC lines to inform the
>monitor of the sync. */
> SPLIT_SYNC,
> /* The monitor uses only one line for both HSYNC and VSYNC. */
> CSYNC,
> /* The monitor uses no seperate line for the sync; it uses one
>of the color lines instead. */
> SYNC_ON_COLOR
> } type;
> union
> {
> struct
> {
> polarity_t hsync_pol;
> polarity_t vsync_pol;
> } split_sync;
> struct
> {
> polarity_t csync_pol;
> } csync;
> struct
> {
> polarity_t pol;
> /* The color line that is used for syncing. */
> enum
> {
> RED,
> GREEN,
> BLUE
> } color;
> } sync_on_color;
> } sync_parameters;
> } syncinfo_t;
>
> typedef unsigned int display_flags_t;
>
Re: SVGA console
Hi Marco,
On Mon, Aug 18, 2003 at 12:02:32AM +0200, Marco Gerards wrote:
> Marco Gerards <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > Currently the console client only support (minimally) VGA. It it not
> > really hard to add some more VGA support and even basic SVGA support.
>
> Today I wrote some code. I got almost everything done, but I want t
> make sure the driver interfaces are sane. These interfaces can be used
> for textmode, but should also be usable for the framebuffer. Do I need
> to add something for textmode and what needs to be done/changed to
> make it more useful for framebuffer support?
>
> Thanks,
> Marco
>
> /* display_driver.h - Video clock interfaces.
>Copyright (C) 2003 Free Software Foundation, Inc.
>Written by Marco Gerards.
>
>This file is part of the GNU Hurd.
>
>The GNU Hurd is free software; you can redistribute it and/or
>modify it under the terms of the GNU General Public License as
>published by the Free Software Foundation; either version 2, or (at
>your option) any later version.
>
>The GNU Hurd is distributed in the hope that it will be useful, but
>WITHOUT ANY WARRANTY; without even the implied warranty of
>MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>General Public License for more details.
>
>You should have received a copy of the GNU General Public License
>along with this program; if not, write to the Free Software
>Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA. */
>
>
struct syncinfo {
enum { SPLIT_SYNC, CSYNC, SYNC_ON_COLOR } type;
union {
struct {
polarity hsync_pol;
polarity vsync_pol;
} split_sync;
struct {
polarity csync_pol;
} csync;
struct {
polarity pol;
enum {RED, GREEN, BLUE} color;
} sync_on_color;
} sync_parameters;
};
typedef unsigned int display_flags;
#define DISPLAY_FLAGS_LACE (1<<0)
#define DISPLAY_FLAGS_EXTSYNC (1<<1)
#define DISPLAY_FLAGS_DOUBLE(1<<2)
> /* Information and interfaces for a display driver. */
> struct display_driver
> {
> /* Name of driver name. */
> const char *driver_name;
>
> /* Name of videocard or videochipset. This information is available
> after initialization with display_init. It can be set to NULL
> when it is not relevant. */
> char *card_sub_name;
>
> /* Maximum allowed values. XXX: Are more maximum values
> required? */
> int max_hdisplay_end;
> int max_hsync_start;
> int max_hblank_start;
> int max_htotal;
> int max_vdisplay_end;
> int max_vsync_start;
> int max_vblank_start;
> int max_vtotal;
>
> /* Initialize display driver. If the hardware is not available or
> usable ENODEV is returned. */
> error_t (*display_init);
>
> /* Deinitialize the driver. */
> error_t (*display_fini);
>
> /* Set the last visible pixel on the display to END. Set the first
> pixel of the horizontal retrace to SYNC_START and its last pixel
> to SYNC_END. Set the last pixel of the screen to TOTAL, after
> this the new line will begin. END, SYNC_START, SYNC_END and
> TOTAL must be multiples of 8. Return EOVERFLOW when the hardware
> can't setup the hardware registers without overflowing them, in
> that case the videomode is not available. */
> error_t (*set_horiz_timings) (int end, int sync_start, int sync_end,
> int total);
>
I wuould rather have :
error_t (*set_horiz_timings) (unsigned xres, unsigned left, unsigned
right, unsigned hslen);
/* set number of visible horizontal pixels to xres,
set number of left margin pixels to left,
set number of right margin pixels to right,
set horizontal sync pulse width to hslen */
> /* Return in END the last visible pixel on the screen, in SYNC_START
> the pixel on which the horizontal retrace starts, in SYNC_END the
> pixel on which the horizontal retrace ends and in TOTAL the last
> pixel of the screen. Never return values that are not usable
> with set_horiz_timings. */
> error_t (*get_horiz_timings) (int *end, int *sync_start, int *sync_end,
> int *total);
>
error_t (*get_horiz_timings) (unsigned *xres, unsigned *left, unsigned
*right, unsigned *hslen)
get equivalent of set_horiz_timings :)
> /* Set the last visible scanline on the display to END. Set the
> first scanline of the horizontal retrace to SYNC_START and its
> last scanline to SYNC_END. Set the last scanline of the screen
> to TOTAL, after this the new vertical period will begin. Return
> EOVERFLOW when the hardware can't setup the hardware registers
> without overflowing them, in that case the videomode is not
> available. */
> error
Re: SVGA console
On Sun, Aug 17, 2003 at 04:55:00PM +0200, Niels M?ller wrote: > 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 think modelines aren't well suited to humans, so they should > probably be hidden somewhere within the driver. > > For configuration, it makes more sense to specify the resolution > (either in rows, columns and character size, or directly in pixels), > desired vertical update rate (frame rate), *optional* tweaks for the > precise timing for syncing, vertical and horisontal blanking etc. And > then let the driver calculate the appropriate figures for the > hardware. > This is not always possible. The timings depend on the monitor connected to the graphics card. So you need a way to figure those out. Modern monitors might support DDC which allows you to query the monitor for modes. DDC however is only available if you use the HD15 VGA connector. There are also VESA standard timings which most PC monitors probably support. Fixed frequency sun/sgi/... monitors probably don't support those. This is only for the PC platform. Macs used to have another autodetection scheme with other standard timings and resolutions. We should probably start by defining a common naming scheme for video modes. The user can then just specify a name and the console can fetch it from a local monitor config file, a global config file containing standard timings or DDC (or some other autoconfig mechanism). I much more like the modefile format used by fbset than the one used by xfree,svgalib etc. It's much easier to understand and maps better with the actual hw. The xfree format is basically a dump of the timing registers of a VGA compatible chip. Cheers, p2. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: creation time as Hurd extension?
On Fri, Jul 18, 2003 at 04:56:15AM -0500, Marcus Brinkmann wrote: > Hi, > > what about having the creation time of a file as an Hurd extension, which is > maintained across copies, like the author? > In that case, why not add an extended attribute scheme ? So everyone can add whatever metadata he wants to a file. Cheers, p2. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: console on oskit-mach
Hi Marcus, On Sun, Feb 16, 2003 at 02:18:29PM +0100, Marcus Brinkmann wrote: > On Sun, Feb 16, 2003 at 01:29:26PM +0100, Peter 'p2' De Schrijver wrote: > > Hi, > > > > I'm trying to get marcus' console to run on hurd with oskit mach. I get > > an illegal instruction exception at the first outb instruction. It seems > > the process does not have the correct I/O permissions to access the VGA > > card. Has anyone tried this before ? I'm running the latest version > > which is the debian packages at alpha.gnu.org. > > You probably need a (newer) glibc library which is compiled against the > latest oskit-mach header files, so ioperm is included. > Ok. Any idea were I can find one more recent than the debian packages on alpha.gnu.org ? > Mmh, you will of course also need the i83265 (or what the number was) driver > by Roland, and boot from a serial console. > Thanks, p2. > Thanks, > Marcus > > -- > `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] > Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ > [EMAIL PROTECTED] > http://www.marcus-brinkmann.de/ -- ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
console on oskit-mach
Hi, I'm trying to get marcus' console to run on hurd with oskit mach. I get an illegal instruction exception at the first outb instruction. It seems the process does not have the correct I/O permissions to access the VGA card. Has anyone tried this before ? I'm running the latest version which is the debian packages at alpha.gnu.org. Any insight ? Thanks, p2. -- ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Program for Embedded & Kernel Development at fosdem 2003
Dear all, Fosdem 2003 will be held 8 and 9 february 2003 in Brussels. See http://www.fosdem.org for more info. The program for the Embedded & Kernel Development Room at fosdem 2003 : Saturday 8/2/2003 = 14:00 - 14:45 : Keynote opencores.org : free hardware development Speaker : Richard Herveille 14:45 - 15:30 : Adapting Debian for Embedded Use Speaker : Martin Michlmayr 16:00 - 16:45 : Portable programming on complex systems Speaker : Peter De Schrijver 16:45 - 17:30 : Wonka - a JVM for embedded systems Speaker : Chris Gray Sunday 9/2/2003 === 10:00 - 11:00 : breakfast + BoF's 11:00 - 11:45 : Cross-compiling in embedded systems Speaker : Eero Tamminen 11:45 - 12:30 : eCos Speaker : Nick Garnett 14:00 - 14:45 : RTAI Speaker : Philippe Gerum 14:45 - 15:30 : GNU Bayonne and real-time issues in freely licensed telephony software Speaker : David Sugar 15:30 - 16:15 : Using C++ for real-time extensions to the Linux kernel Speaker : Peter Soetens Cheers, Peter. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: 2nd attemt at reviving the filesystem limit discussion.
On Fri, Dec 06, 2002 at 03:53:42PM -0500, Neal H. Walfield wrote: > 64-bit systems do not necessarily give you 64-bits of virtual address > space (even discounting the kernel's area). Alpha, for instance, only > gives you 43 bits. There are real practical reasons for doing this: > the page tables become far too deep and costly for no benefit (8k > pages => 13 bits + 10k entries per page table * 3 levels of page > tables). If you use 8Kbyte pages. 64Kbyte pages gives you already 55 bits of virtual address space. :) Cheers, p2. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: 2nd attemt at reviving the filesystem limit discussion.
On Fri, Dec 06, 2002 at 11:52:52AM -0600, Tom Hart wrote: > Peter 'p2' De Schrijver wrote: > >On Fri, Dec 06, 2002 at 05:46:13PM +0100, Marcus Brinkmann wrote: > >>The reason for the limit is because the address space on IA32 architecture > >>is 32 bit. Now, you _could_ of course change the kernel interfaces to > >>allow > >>for larger memory objects and only limit mapping windows to 4gb. This > >>might > > > > > >Or you could just use a 64bit machine such as an alpha ? :) > > > >Always looking for a hardware solution to a software problem, > > So then the problem goes away *for now*. Remember that hard drive sizes > have this habit of doubling every year or so. Isn't this a re-statement > of "640 K ought to be enough for anyone"? True, it's not a solution forever. Cheers, p2. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: 2nd attemt at reviving the filesystem limit discussion.
On Fri, Dec 06, 2002 at 05:46:13PM +0100, Marcus Brinkmann wrote: > On Fri, Dec 06, 2002 at 11:05:13AM +0100, M. Gerards wrote: > > Another thing I wonder: Why do memory > > objects have a maximum size of 4GB? Isn't it possible to create a memory object > > with the size of the entire store and use mapping windows? (Or am I confused > > again? :)). Can someone please describe how this works in more detail if I'm > > wrong? I assume more people are confused by this. > > The reason for the limit is because the address space on IA32 architecture > is 32 bit. Now, you _could_ of course change the kernel interfaces to allow > for larger memory objects and only limit mapping windows to 4gb. This might Or you could just use a 64bit machine such as an alpha ? :) Always looking for a hardware solution to a software problem, p2. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: GNU Mach 2's serial console doesn't work?
On Wed, Nov 06, 2002 at 05:51:51PM +0100, Marcus Brinkmann wrote:
> Hi,
>
> I just tried to boot OSKit Mach with a serial console. It doesn't work
> anymore! Has anybody got it to work recently, or can reproduce this bug?
> Does anybody have two serial cables to debug this? (Else I have to buy
> another one).
>
> Here is what happens (in minicom with GRUB on serial console):
>
> root (hd1,0)
> Filesystem type is ext2fs, partition type 0x83
> kernel /boot/gnumach2.gz -h CONS_COM=2 BAUD=9600 root=device:hd2s1 --
>[Multiboot-elf, <0x10:0x14c794:0x0>, <0x24d000:0x17920:0x2da44>,
> shtab=0
> x293280, entry=0x10]
> module /hurd/ext2fs.static --readonly
> --multiboot-command-line=${kernel-command
> -line} --host-priv-port=${host-port} --device-master-port=${device-port}
> --exec
> -server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume)
>[Multiboot-module @ 0x2cf000, 0xc8604 bytes]
> module /lib/ld.so.1 /hurd/exec $(exec-task=task-create)
>[Multiboot-module @ 0x398000, 0x25295 bytes]
>
> Welcome to GNUmach 1.90!
>
> and then it just sits there.
>
I have seen similar things. I suspect that serial console without GDB
stub does not work. You can do serial console and GDB stub on the same
serial link however. Otherwise you will have to make/buy an extra cable
:)
Cheers,
p2.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Mach ports use
On Mon, Oct 28, 2002 at 10:53:27PM +0100, Niels Möller wrote: > [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 server's access to the container > > or fill it with another pay load and continue. > > I'm out on somewhat thin ice here, but I've heard the following > explanation of network card programming: > > The network card and the driver shares two circular buffers containing > data and some control information. The network card uses dma to read > data from the send queue, and to write to the receive queue. > Typically you have two lists of pointers. 1 list points to buffers containing data to be transmitted. The other list points to buffers available for incoming frames. Apart from the pointers to the buffers, the list entries also contain status information. Some chips can read/write 1 frame from/to multiple buffers. So you can put the headers in another buffer than the user data (think of it as hw support for a chain of mbufs). That's for the more intelligent cards. Dumber chips (eg, the rtl8139) just have a ring buffer for reception (which contains the incoming frames, not pointers) and some registers containing pointers to memory blocks to be transmitted. In this case you're almost forced to copy data on reception. Some older 10Mbps only cards don't support DMA at all. You have to use PIO to get data in and out of the packet buffer. This is typically the case for all 8390 based cards (NE2k and the likes). > One generally wants a circular queue with more than one element, so > that the network card immediately can go on getting the next packet to > transmit, without having to wait for the operating system to process > interrupts, and then tell it to go on. > Indeed you typically need a few buffers ready for incoming frames and you obviously want to fill the transmit list so the card can transmit frames as fast as possible. > My (possibly naive) view on how to do this on l4 would be to share > some memory with the driver, preferably memory of some type that can > be used directly for dma. The i/o client would write data at the tail > of the circular queue (or wait until space becomes available), and > then make an rpc to the driver. The driver would fill out the > (hardware-dependent) control information, and make sure the packet is > scheduled for transmission by the networking card. While the packet is > being queued and transmitted, the client will go on, trying to enqueue > more packets, or doing other work. > For transmission : I would just have the client transfer the ownership of the page containing the data to the driver. The driver can then add a pointer to this data to the transmit queue. When the frame is transmitted, the page can be released. Cheers, p2. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
