若不指定“vga=”参数，系统则不支持framebuffer设备，为什么呢？在内核代码中是如何实现的？
查看系统启动日志kern.log发现，指定“vga= ”比不指定多了一下几行：

Apr 25 17:14:03 nmr107 kernel: vesafb: framebuffer at 0xd0000000, mapped to 0xe0880000, using 6144k, total 65536k
Apr 25 17:14:03 nmr107 kernel: vesafb: mode is 1024x768x32, linelength=4096, pages=1
Apr 25 17:14:03 nmr107 kernel: vesafb: protected mode interface info at c000:f6d0
Apr 25 17:14:03 nmr107 kernel: vesafb: pmi: set display start = c00cf715, set palette = c00cf79a
Apr 25 17:14:03 nmr107 kernel: vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03
Apr 25 17:14:03 nmr107 kernel: vesafb: scrolling: redraw
Apr 25 17:14:03 nmr107 kernel: vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
可以看出这里设置了vesafb模式

搜索的源代码，发现在/drivers/video/vesafb.c的函数vesafb_probe中，printk输出了以上信息
那么，是哪个函数调用vesafb_probe的呢？继续找。。发现只有这个与vesafb_probe有关
static struct platform_driver vesafb_driver = {
.probe = vesafb_probe,
.driver = {
  .name = "vesafb",
},
};
很明显，必定有哪个地方通过 “->probe” 调用vesafb_probe。搜索关键词“->probe” ，竟然只有几个，都不相关。改搜“>probe”,这一次还不少。去掉一些明显不可能的（如 pci，usb下的)，找到最有可能的 driver_probe_device函数（/drivers/base/Dd.c文件中）。照此思路，依次找到__driver_attach（调用driver_probe_device），driver_attach（调用__driver_attach）
bus_add_driver（调用driver_attach），driver_register（调用bus_add_driver），platform_driver_register（调用driver_register），vesafb_init（调用platform_driver_register），最后module_init(vesafb_init)
而通过module_init指定的函数，会在do_initcalls中调用 接着do_basic_setup（调用
do_initcalls），init（调用do_basic_setup）。至此，终于弄明白vesafb_probe的被调用过程。

哪没有输出vesafb信息，是在那一步中断的呢？逐步跟踪，终于眼前一亮：
if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB)
  return -ENODEV;
据我所知，screen_info是与“vga=”参数有密切关系的！查看VIDEO_TYPE_VLFB定义
#define VIDEO_TYPE_VLFB  0x23 /* VESA VGA in graphic mode */
正是想要的。

进一步验证，screen_info的元素orig_video_isVGA位于距起点“0x0f”处。继续往回找，
有screen_info = SCREEN_INFO;
而
#define PARAM (boot_params)
#define SCREEN_INFO (*(struct screen_info *) (PARAM+0))
在/arch/i386/kernel/head.s文件中找到这么一段
/*
* Copy bootup parameters out of the way.
* Note: %esi still has the pointer to the real-mode data.
* With the kexec as boot loader, parameter segment might be loaded beyond
* kernel image and might not even be addressable by early boot page tables.
* (kexec on panic case). Hence copy out the parameters before initializing
* page tables.
*/
movl $(boot_params - __PAGE_OFFSET),%edi
movl $(PARAM_SIZE/4),%ecx
cld
rep
movsl
注释意思说，将启动参数拷贝到boot_params指向的地方。在vedio.s中，有相关代码处理vesa驱动。
mopar_gr:
leaw modelist+1024, %di
movb $0x23, %fs:(PARAM_HAVE_VGA)
。。。。。。
而PARAM_HAVE_VGA定义为
#define PARAM_HAVE_VGA  0x0f

这里说明一点，“vga=”参数由grub处理，处理结果放在内核文件vmlinuz的头部的vidmode处。
linux启动开始，读取该值
movw %fs:(0x01fa), %ax  # User selected video mode
cmpw $ASK_VGA, %ax   # Bring up the menu
jz vid2
call mode_set   # Set the mode
这里%fs:(0x01fa)就是引用内核映像中vidmode处
内核头部在bootsect.s中能看到
.org 497
setup_sects: .byte SETUPSECTS
root_flags: .word ROOT_RDONLY
syssize: .word SYSSIZE
swap_dev: .word SWAP_DEV
ram_size: .word RAMDISK
vid_mode: .word SVGA_MODE
root_dev: .word ROOT_DEV
boot_flag: .word 0xAA55

总结：写了这么多，估计没几个人能看懂或看完。不过，我只当是记录一下读核的一点艰辛过程。
内核代码的阅读，要花费很多的精力，翻看成千上万行代码，不停的跟踪函数调用过程。这时候，
要有一定的技巧，更要有耐心。