Vladimir 'phcoder' Serbinenko wrote:
> I will do this. I know you already had some work for mm underway that's why
> I wasn't doing it. Could you send what you already have even if it's far
> from complete?
Sorry. Everything got lost on laptop.
___
G
an't remember anything else for this occasion what important would have
been under the work.
I might read this mailing list occasionally, but don't be suppriced if I
do not notice questions addressed to me.
Thanks,
Vesa Jääskeläinen
___
Grub-devel
Vladimir Serbinenko wrote:
> Hello, currently vbe module contains all the framebuffer functions which are
> actually adapter-independent and I think more adapters can be implementing
> by providing a function which sets mode and framebuffer. Additionally it
> provides an interface to retrieve frame
Bean wrote:
> Hi,
>
> This patch integrate the LUA script engine to grub2. Before applying
> this patch, you should apply the split module patch split_3.diff
> first.
>
> BTW, I forget to add Makefile.in the previous split_3.diff, so that
> handler.lst will not be generated, I include it in this
there any other needs?
So what does people feel about these changes. I am afraid if too much
freedom is given it will make it complex...
Thanks,
Vesa Jääskeläinen
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo
phcoder wrote:
> This usage case isn't the main target case. If you embed the loader
> (which tend to be quite big) then you already have an overhead from
> loader module. Why are you so concerned with overhead of boot.mod?
> But on the other hand this forces all the people in other cases to have
>
Bean wrote:
> Also, some thoughts about grub2 authority. I do understand the needs
> to keep source clean and safe for a boot loader, but sometimes the
> process just seems too slow. For example, Colin's graphic menu patch
> has been pending for almost half a year. IMO, if a patch implement a
> gen
Yoshinori K. Okuji wrote:
> On Sunday 29 March 2009 22:23:11 Vesa Jääskeläinen wrote:
>> Both of those projects has divided work force dedicated to maintain and
>> drive enhancements to defined goals.
>>
>> Now if we map this to our situation:
>>
>> - We are
Yoshinori K. Okuji wrote:
> On Sunday 29 March 2009 20:40:17 David Miller wrote:
>> Everybody is too busy to give this project the attention and time it
>> deserves to be maintained properly.
>>
>> I honestly do not think the situation will change significantly until
>> someone is able to devote re
Vesa Jääskeläinen wrote:
> Yoshinori K. Okuji wrote:
>> Any objection?
>
> Not really. I will make some grief, but it might be a good thing in overall.
Just to make it clear:
It will... ;)
___
Grub-devel mailing list
Grub-dev
Here I must comment that in some cases it is favorable to do it this
way. I personally will only commit changes that I am happy to live with.
Even if you are developer with SVN commit rights it is in some cases
good idea to have general review of the patch... but there has been some
lack of the tim
Yoshinori K. Okuji wrote:
> You should select compile-time "loading" (i.e. linking) whenever possible. If
> a function is loaded eventually, it should be linked at compile time.
>
> You should select automatic loading, if you need runtime linking.
>
> Manual loading should be considered evil, in
Bean wrote:
> Hi,
>
> This patch split the function of normal mode into small modules, here
> is a summary:
>
> 1, Move dynamic command loader to commands/dyncmd.c (dyncmd.mod)
> 2, Move automatic fs loader to fs/autofs.c (autofs.mod)
> 3, Split normal mode into three major parts:
> parser/normal
Bean wrote:
> Hi,
>
> Currently, the grub-emu is in every rmk files, but I don't see the
> difference between grub-emu in i386-pc, i386-coreboot or i386-efi. In
> fact, grub-emu runs inside the host os, it can't access firmware
> facility anyway. One quick fix to move grub-emu to i386.rmk, but we
Pavel Roskin wrote:
> By the way, I already noticed that the inclusion of stdint.h from
> multiboot2.h is one of the problems preventing cross-compilation of GRUB
> without the libc for the target. Perhaps GRUB should provide its
> replacement for stdint.h when compiling for the target. Alternati
phcoder wrote:
> Actually if it was up to me I would have removed setjmp altogether. IMHO
> it's a bad programming technique. It's used only to launch rescue mode.
> I would just call the rescue mode interpreter by function. Perhaps Bean
> who is working on normal.mod splitting has even better idea
phcoder wrote:
> Hello. I propose to create a symlink normal/cpu. This way normal.mod can
> be moved to conf/common.rmk. Works fine on i386-pc. Can people having
> other platforms test?
I do not like the fact that you hardcoded filenames what can be on
platform dependant parts.
I have also though
Colin D Bennett wrote:
> This long-awaited patch adds graphical menu support to GRUB 2. It is
> largely the result of my work during the Google Summer of Code 2008.
>
> The graphical menu system supports image-based themes, of which I have
> created several sample themes[1].
>
> There are still
Bean wrote:
> On Sat, Mar 21, 2009 at 5:41 PM, Yoshinori K. Okuji wrote:
>> Hi all,
>>
>> I would like to know if anybody wants to be a mentor in this year for Google
>> SoC. If none, I must tell Karl (the coordinator of the GNU participation to
>> SoC) to get rid of the link to GRUB. Otherwise, I
David Miller wrote:
> One issue I need to resolve before I can send finalized
> patches out for sparc is about device naming.
>
> Currently the PowerPC ieee1275 support allows using both device
> aliases and full openfirmware device path names with the usual GRUB
> partition specification concaten
Robert Millan wrote:
> On Fri, Mar 06, 2009 at 08:57:35PM +0100, Robert Millan wrote:
>> This patch integrates the generic Linux loader with gfxterm. The result is
>> that graphical mode becomes usable with this loader. Our loader gets the
>> screen settings from the video subsystem (as per gfxte
phcoder wrote:
> Hello. Discussing with Robert Millan and Bean on IRC we noticed that
> disk cache index is statically allocated. Here is a proposal to change
> it to dynamic allocation proportional to the size of available memory.
And the gain is ?
__
Robert Millan wrote:
> This patch makes the generic Linux loader usable on i386-pc again. It
> doesn't seem like it's badly needed to spend a bit of time and a bit of
> code in adding low memory to the heap, and Vesa's work on the new memory
> manager should give a proper solution to this problem.
David Miller wrote:
> From: Vesa Jääskeläinen
> Date: Wed, 04 Mar 2009 13:59:43 +0200
>
>> David Miller wrote:
>>> In order for the boot block images for sparc to work properly,
>>> we have to strip them out before doing the objcopy.
>>>
>>> Thi
David Miller wrote:
> Are you going to apply my patches or do I have to rewrite
> everything?
Personally I have nothing against resurrecting sparc support :)
Lets see what kind of other comments they generate...
___
Grub-devel mailing list
Grub-devel
David Miller wrote:
> In order for the boot block images for sparc to work properly,
> we have to strip them out before doing the objcopy.
>
> This is harmless on i386-pc and some other future grub
> targets might need this too, so do it universally.
Please have a look at mail from me with subjec
David Miller wrote:
> Many of these warnings are for two reasons:
>
> 1) grub_ssize_t is != 'int' on sparc64, and many pieces of code
>try to pass an int pointer in for the final arg of several
>ieee1275 "get property" functions which take a grub_ssize_t
>pointer.
>
> 2) The third arg
David Miller wrote:
> There is no way anyone tried to build the sparc target in
> years :-) This updates sparc64-ieee1275.rmk with modern
> times and regenerates sparc64-ieee1275.mk as well as
> DISTLIST.
>
> 2009-03-03 David S. Miller
>
> * conf/sparc64-ieee1275.rmk: Update.
> * co
David Miller wrote:
> 2009-03-03 David S. Miller
>
> * include/grub/sparc64/ieee1275/loader.h: New file.
> * include/grub/sparc64/ieee1275/memory.h: Likewise.
> * include/grub/sparc64/kernel.h: Likewise.
> * loader/sparc64/ieee1275/linux.c: Likewise.
> * loader/spa
David Miller wrote:
> This replaces the C implementation with a proper assembler
> one. Also add missing grub_prefix[] declaration to
> kernel.h
>
> 2009-03-03 David S. Miller
>
> * kern/sparc64/ieee1275/init.c: Delete, replace with...
> * kern/sparc64/ieee1275/crt0.S: assembler i
David Miller wrote:
> Here is a series of patches that fix the most obvious sparc bugs and
> get the grub2 tree building again.
>
> I have code for boot/ that will implement the sparc boot blocks and
> things of that nature, but that will come later.
>
> First things first, let's get it to actual
David Miller wrote:
> This corrects the sparc64 setjmp implementation.
>
> We need to store the return address register, the
> stack pointer, and frame pointer into the jump buf.
>
> And on longjmp we need restore those registers, flush the register
> window state, and pull in the top-most regist
David Miller wrote:
> + stx %g1, [%sp + 2047 + (14 * 8)]
> +retl
> + restore %o1, 0, %o0
Please check your white spaces. As we can see here those three commands
are on different columns (mixed tabs and spaces). This applies to every
other patch you sent too...
Robert Millan wrote:
> It's funny, we're all discussing about performing security measurements in
> GRUB and nobody mentioned that our user interface lacks even the most basic
> lock mechanism :-)
>
> Perhaps this would be a good time to retake the discussion on implementing
> an equivalent to "lo
Jan Alsenz wrote:
> Vesa Jääskeläinen write:
>> I do like the idea what some protected systems use, they sign the binary
>> (in our case .mod file and kernels of loaded OSes). Now in that scenario
>> it is responsibility of the kernel module loader to first verify the
>>
Hi All,
Ok. Please keep the fighting of TPM out of this thread ;). Lets keep it
to the topic first... (I am already waiting for summary of that other
discussion at some point ;))
Jan Alsenz wrote:
> Next I think we can agree, that some sort of trusted boot chain can be useful.
>
> Also there sho
to another time :).
Tips for RM code debugging: 'set arch i8086' and 'x/10i ($cs<<4)+$eip'.
Thanks,
Vesa Jääskeläinen
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
have
QEMU debugging working. And as this step is shared between those two I
propose that this work is sliced to two pieces.
Thanks,
Vesa Jääskeläinen
Index: ChangeLog
===
--- ChangeLog (revision 1999)
+++ ChangeLog (working cop
Jan Alsenz wrote:
> I agree too!
>
> Multiple methods are interesting and everything that can be, should be placed
> in
> modules.
> But some parts of a trusted boot chain need to be in the MBR, etc. which is
> mainline code (regardless of how how you build it).
>
> The way I have implemented m
Bean wrote:
> On Sat, Feb 14, 2009 at 11:11 PM, Felix Zielcke wrote:
>> A. Am Samstag, den 14.02.2009, 22:46 +0800 schrieb Bean:
>>
>>> If there is no objection, I'd commit this patch in a few days.
>> Hello Bean,
>>
>> if you want to drop termin_input and terminal_output command then please
>
BandiPat wrote:
> Vesa Jääskeläinen wrote:
>> phcoder wrote:
>>> Hello. I've run into the bug that when editing menu entry in gfxterm
>>> characters disappear after cursor moves away from its position. Here is
>>> bugfix
>>
>> I don't think
phcoder wrote:
> Hello. I've run into the bug that when editing menu entry in gfxterm
> characters disappear after cursor moves away from its position. Here is
> bugfix
I don't think this is a clean fix:
> Index: term/gfxterm.c
> ===
te that part of the
code so it can also handle text modes.
Thanks,
Vesa Jääskeläinen
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Felix Zielcke wrote:
> Am Sonntag, den 01.02.2009, 21:08 +0100 schrieb Felix Zielcke:
>> grub_emu-normal_main.o: In function `grub_mod_init':
>> /home/fz/grub/grub2.svn/normal/main.c:623: undefined reference to
>> `grub_menu_viewer_register'
>> grub_emu-normal_main.o: In function `grub_normal_exec
Felix Zielcke wrote:
> grub_emu-normal_main.o: In function `grub_mod_init':
> /home/fz/grub/grub2.svn/normal/main.c:623: undefined reference to
> `grub_menu_viewer_register'
> grub_emu-normal_main.o: In function `grub_normal_execute':
> /home/fz/grub/grub2.svn/normal/main.c:580: undefined referenc
BandiPat wrote:
> Compiled and installed grub2. Remove LILO from MBR. Ran grub-install
> /dev/sda. Run grub-setup /dev/sda. Ran update-grub to let it create a
> grub.cfg file. So far, so good and checking everything, it all looks
> great according to the instructions I have been able to find.
Hi,
As this patch is quite large and I am going go to sleep soon so I only
comment your message on this run...
Colin D Bennett wrote:
> This long-awaited patch adds graphical menu support to GRUB 2. It is
> largely the result of my work during the Google Summer of Code 2008.
And thanks for it!
Colin D Bennett wrote:
> This patch improves the videotest command by adding a number of
> different tests for particular features. The 'videotest text' test
> tests the rendering of Unicode UTF-8 text, for instance, and the
> 'videotest bench' command runs a video performance benchmark. The
> or
Colin D Bennett wrote:
> This patch adds bitmap scaling support to GRUB.
>
> It also adds support to gfxterm for scaling the background image to fit
> the screen. The background_image command supports a new -m/--mode
> option, which takes "stretch" (the default) or "normal" as values.
>
> The pa
Colin D Bennett wrote:
> This patch adds double buffering support support to the VBE
> video driver including page flipping and blitting from an offscreen back
> buffer.
>
> The patch is against GRUB trunk revision 1964.
Unless we come up with better idea we can go with this time being...
Check t
Colin D Bennett wrote:
> This patch adds support for multiple fallback entries in grub.cfg.
>
> I'll prepare the ChangeLog entry when the patch is approved to be
> committed.
>
> The patch is against GRUB trunk revision 1964.
What do you think if all text menu related would be moved to own file,
lt list and commit
small changes yourself.
Thanks,
Vesa Jääskeläinen
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Jay Sullivan wrote:
> 1) Mailing lists:
>
> I'm wanting to avoid asking questions that have already been answered, and
> I'd like to keep up on current issues with grub2, so I'd like to try to keep
> the grub-devel mailing list sorted...but I'm clueless.
> First of all, is it strange of me to ask,
phcoder wrote:
>> I do not remember seeing a problem here. So what is actually the problem
>> and how to reproduce it?
>
> I booted GRUB2 by GRUB-Legacy, command prompt appeared and worked but
> there were no cursor. I think the same problem appears when the user
> opens command line from the menu
phcoder wrote:
> Testing grub I noticed this bug. Here is bugfix
> Vladimir 'phcoder' Serbinenko
>
> Index: normal/cmdline.c
> ===
> --- normal/cmdline.c(revision 1959)
> +++ normal/cmdline.c(working copy)
> @@ -148,6 +148,7 @
Matt Turner wrote:
> Hi,
>
> I learned today that GRUB 2 aims to be cross platform and already
> supports in some form PPC.
>
> Is there any interest in supporting the DEC Alpha (SRM) platform?
If you are planning to provide the code for it and maintain it :) (or
someone else).
> Alpha users cu
Michel Dänzer wrote:
> P.S. Please reconsider automatically rejecting posts from
> non-subscribers. I co-moderate half a dozen mailing lists, only costs me
> a couple of minutes a day thanks to a nice tool called 'listadmin'.
grub-devel is a subscriber only list.
Javier Martín wrote:
> A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
> $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
> to arise even with cross compilation enabled.
>
> AFAIK, the full power of $build+$host+$target only matters when building
> _compi
Javier Martín wrote:
> This patch modifies several files in the build system (mainly common.rmk
> and genmk.rb) to reduce the general verbosity of the build process to a
> manageable, semi-informative level. Thus, what currently appears as
> "gcc" calls, several lines long each is turned into lines
Carles Pina i Estany wrote:
> Hello,
>
> On Jan/24/2009, Carles Pina i Estany wrote:
>
>> In Grub command line I really miss a cat with pagination (like
>> more/less). Any reason that it's not here? I don't remember if we
>> discussed it. Or it's there and I have not found.
>
> I've just remembe
jida...@jidanni.org wrote:
> Gentlemen, there is a serious usability problem with cmdline.c.
>
> At the very start the user sees the message made by
>
> grub_printf ("\
> [ Minimal BASH-like line editing is supported. For the first word, TAB\n\
>lists possible command completions. Anywhere
Carles Pina i Estany wrote:
> Hello,
>
> (I'm not Grub expert)
>
> On Dec/27/2008, jida...@jidanni.org wrote:
>> Please add this somewhere you feel comfortable with in grub.texi.
>>
>> I looked, but cannot find the right place.
>>
>> Thank you.
>>
>> @Chapter Tips
>> @node Forgot the root passwor
jida...@jidanni.org wrote:
> I sent patches etc. last month, Subjects:
> [PATCH] grub-install message should mention --recheck
> [semi-PATCH] grub.texi: emergency booting without root passwd
> cmdline.c: ESC at any time exits: only mentioned once
> but nobody acted on them one way or the other
Carles Pina i Estany wrote:
> Hello,
>
> On Jan/21/2009, Vesa Jääskeläinen wrote:
>> Carles Pina i Estany wrote:
>>> -I have seen that Grub2 is not printing correctly the accents,
>>> could be a problem in gettext or in some other layer
>> Please provide
Carles Pina i Estany wrote:
> -I have seen that Grub2 is not printing correctly the accents,
> could be a problem in gettext or in some other layer
Please provide example what is wrong and how it should look like.
___
Grub-devel mailing list
Grub-devel
Felix Zielcke wrote:
> Here's a little patch for Makefile.in to use the new grub-mkfont to
> create the font files.
> Is it okay or is there a better way to do this?
Please remove the java code & toolchain with the same change.
___
Grub-devel mailing l
Bean wrote:
> Hi,
>
> This patch converts existing font to pf2. It uses the freetype2
> library, so it can support most common file format, like bdf, pcf.gz,
> ttf, etc.
>
> Usage: grub-mkfont [OPTIONS] FONT_FILES
>
> Options:
> -o, --output=FILE_NAMEset output file name
> -i, --index=N
Vesa Jääskeläinen wrote:
> Couple of days went and now patch finally went in. I have updated
> gfxterm part of the wiki to match new font enngine:
I also moved common video subsystem code to common.rmk so that other
architectures builds nicely too :)
This does not however mean th
Jerone Young wrote:
> Hey guys,
>
> I wanted to start up a discussion on building a steady release
> cycle. Many distros are now looking for some stability from Grub 2 as they
> are looking to include it in future releases. I was recently at the Ubuntu
> Developer Summit in December discus
Bean wrote:
> Hi,
>
> Unicode characters are split into two sizes, 16x16 and 16x8, and are
> stored in different files, for example:
>
> f16.pcf.gz
> -efont-fixed-medium-r-normal--16-160-75-75-c-160-iso10646-1
>
> h16.pcf.gz
> -efont-fixed-medium-r-normal--16-160-75-75-c-80-iso10646-1
>
> They
Colin D Bennett wrote:
> This would be fairly simple to do. The font would then effectively be
> a proportional-width font since the new font engine+gfxterm does not
> handle "bi-width" fonts in a character-cell environment.
Actually it does :)... In a way at least.
If you have lets say Hiragana
Colin D Bennett wrote:
> On Fri, 2 Jan 2009 16:44:49 -0600
> "Jerone Young" wrote:
>
>> I just paid attention to this (sorry). So everything seems fine. But
>> the dependency on a proprietary java stack to generate fonts isn't
>> good. Does it happen to work with gcc java ?
>
> The font tool d
Jerone Young wrote:
> I just paid attention to this (sorry). So everything seems fine. But the
> dependency on a proprietary java stack to generate fonts isn't good. Does
> it happen to work with gcc java ?
Paying attention is not a bad thing as such :)
Never tried it myself but it should work.
Vesa Jääskeläinen wrote:
> Hi All,
>
> I am about to integrate Colin's new Font Engine with additional changes
> to gfxterm.
>
> This means that current font tool chain will be obsolete and there will
> be new font commands to load fonts and so on. These will be de
Vesa Jääskeläinen wrote:
> And the actual patch...
... went it. Instructions being updated... with another post when ready.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
vert your fonts. These will be documented on
Wiki once committed.
2008-12-28 Colin D Bennett
New font engine.
Additional changes by Vesa Jääskeläinen to adapt to
build system and fixed gfxterm.c to work with different sized fonts.
* configure.ac: Changed
Colin D Bennett wrote:
> On Sat, 06 Dec 2008 22:18:14 +0200
> Vesa Jääskeläinen wrote:
>
>> Colin D Bennett wrote:
>>> Update:
>>>
>>> I fixed an error pointed out to me by Y.Volta:
>>> In grub_font_get(), if no fonts are loaded, a null
There are sill some patches that will need attention, but
basically almost all ground work is after that ready.
Next I will do some cleanup for the patch and try to commit it withing
couple of days.
Thanks,
Vesa Jääskeläinen
___
Grub-devel mailing list
phcoder wrote:
> Hello,all. I was busy studying so wasn't watching the list. Is there a
> particular reason why my patch still isn't incorporated?
Perhaps we didn't like the move of loader/boot core functionality out of
kernel?
And I do not remember you describing in detail about interfaces and
f
Robert Millan wrote:
> On Tue, Dec 09, 2008 at 04:13:46PM +0530, Varun Deshpande wrote:
>> hi
>> I am interested to contribute something in open source. I would like to
>> contribute something for grub. I downloaded source code of grub-1.96 & in
>> TODO file i got this mail id.
>> I am ve
James Shewey wrote:
> Grub will not currently compile on 64 bit distros. Try compiling with a 32
> bit live cd or a 32 bit VM (you can try virtualbox.org for this) and then
> copying the requisite files to the 64 bit OS.
I compile GRUB 2 SVN always on 64 bit Ubuntu...
So please try with SVN ver
/unifont.pf2
lsfonts gives:
Loaded fonts:
Unknown -1
Is this expected?
Thanks,
Vesa Jääskeläinen
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Jay Sullivan wrote:
> Okay! I realized now that I would like to install the newest version of
> grub2 to a USB drive. Can anyone recommend to me the best way to do this?
> This seems like a good idea since if it fails to boot, I can easily fallback
> to my harddrive's bootloader.
>
> I'd like to
Manoel Rebelo Abranches wrote:
> On Mon, 2008-12-01 at 19:01 +0200, Vesa Jääskeläinen wrote:
>> Manoel Rebelo Abranches wrote:
>>> This patch add --build-id=none option to newer ld versions when linking
>>> kernel.elf.
>>> This prevents grub-mkelfimage t
Manoel Rebelo Abranches wrote:
> This patch add --build-id=none option to newer ld versions when linking
> kernel.elf.
> This prevents grub-mkelfimage to behave wrongly.
> if test "x$grub_cv_prog_ld_build_id_none" = xyes; then
>MODULE_LDFLAGS="$MODULE_LDFLAGS -Wl,--build-id=none"
> + PPC_BU
one.
However just walking the source code and trying to understand everything
might be boring task. So I would prefer that take some of the bugs and
see how they work (or why they wont) and then discuss it. Please skip
bug reports about GRUB legacy and look at GRUB 2 issues if you go that path.
https://savannah.gnu.org/bugs/?group=grub
Thanks,
Vesa Jääskeläinen
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Robert Millan wrote:
> On Tue, Nov 25, 2008 at 10:23:52PM +0100, Yoshinori K. Okuji wrote:
>>> I've been thinking... what if we make this generic? I.e. with an event
>>> loop, then terminals can register their poll functions to it, and write
>>> their stuff to a shared resource the rest of GRUB ca
Robert Millan wrote:
> On Tue, Nov 25, 2008 at 10:17:17PM +0100, Yoshinori K. Okuji wrote:
>> On Saturday 22 November 2008 16:35:09 Robert Millan wrote:
>>> When an error is detected by ata.mod during drive scan, it will pass it to
>>> the upper layer. This results in GRUB aborting when trying to
ted
so it can be merged.
In meanwhile you can try to determine your IO base address and try it
out with serial's --port=0x argument. With luck you are fine.
Please report what kind of card you have and some details about it (in
example verbose dump of lspci with your serial card sect
bus, int dev, int func, grub_pci_id_t pciid)
> + vid = pciid & 0x;
> + did = pciid >> 16;
> + addr = grub_pci_make_address (bus, dev, func, 2);
> + w = grub_pci_read (addr);
> + class = (w >> 16) | ((w >> 8) & 0xff);
> + addr = grub_pci_mak
Robert Millan wrote:
> Hi,
>
> I think it would be good to make at_keyboard the default input terminal on
> i386-ieee1275, after the kernel has loaded (via grub-mkconfig). The AT
> keyboard is the only choice on OLPC anyway, and avoids ofconsole bugs
> (this used to be the old behaviour before th
Robert Millan wrote:
> On Sat, Nov 08, 2008 at 06:58:19PM -0700, [EMAIL PROTECTED] wrote:
>> Note that what I'm doing will make the serial module dependent upon the
>> pci module but I don't see that that's a big concern. Pretty much any
>> modern machine will have a PCI bus so scanning it should
Robert Millan wrote:
> Sounds good. But do we have support for "weak" symbol dependencies a la
> dlym() ?
I tried it once while traveling and you can dynamically check for
function symbols and then start using them if they are loaded. Thou... I
do not know how reference counting is then affected.
Robert Millan wrote:
> On Fri, Nov 07, 2008 at 06:52:21PM +0200, Vesa Jääskeläinen wrote:
>> [EMAIL PROTECTED] wrote:
>>> Bad news, I heard back from the two people who wrote the PCI serial
>>> code for Linux (Russell King & Ted Tso) and they both agree that,
>
[EMAIL PROTECTED] wrote:
> Bad news, I heard back from the two people who wrote the PCI serial
> code for Linux (Russell King & Ted Tso) and they both agree that,
> no matter how the ambiguity got into the Linux source files, their
> intent was that the code was GPL v2 only.
>
> That being the cas
Colin D Bennett wrote:
> On Fri, 31 Oct 2008 18:31:31 +
> "Matt Sturgeon" <[EMAIL PROTECTED]> wrote:
>
>> will all these fonts be included in the next release of GRUB 2?
>
> Probably not; the licenses may not be compatible with GPLv3. These
> fonts are ones that came with X.Org on my system,
Robert Millan wrote:
> On Tue, Nov 04, 2008 at 08:55:52PM +0200, Vesa Jääskeläinen wrote:
>> Robert Millan wrote:
>>> On Sat, Nov 01, 2008 at 01:32:29PM +0100, Robert Millan wrote:
>>>> Hi,
>>>>
>>>> Attached patch makes it possible to build mo
Robert Millan wrote:
> On Sat, Nov 01, 2008 at 01:32:29PM +0100, Robert Millan wrote:
>> Hi,
>>
>> Attached patch makes it possible to build modules externally, by:
>>
>> - Installing headers in system include dir.
>>
>> - Exporting two ABI tags (a build-time macro and a run-time variable)
>>
Robert Millan wrote:
> Hi,
>
> This patch splits terminal handling in input and output. While at it, it
> resolves/removes some of the kludges we had to work around this limitation.
>
> For example, gfxterm/vga no longer need to assume the input is bios console,
> at_keyboard can be used in comb
Yoshinori K. Okuji wrote:
> BTW, I would like to obtain the capability of handling pipes, so that we can,
> say, "help | more". I guess you have the same idea in your mind. This should
> be trivial, once the input and output are separate, right?
I think this would need separated streams design i
1 - 100 of 427 matches
Mail list logo
