Модератор: terminus
почему нет? будет на подобии opensolaris.koparadox писал(а):насчет того что бы xemu86 модулем делать - не уверен
ну ладно посмотрим реакциию вообще
не понял. У мя в sys/modules/vesa/Makefileparadox писал(а):модуль должен что то делать
а в данном случае сам xemu86 будет компиляться вместе с тем кто его требует
vesa или dpms
либо и там и там тоесть дважды
Код: Выделить всё
# $FreeBSD$
KMOD= vesa
SRCS= opt_vga.h opt_vesa.h
.PATH: ${.CURDIR}/../../dev/fb
SRCS+= vesa.c
.PATH: ${.CURDIR}/../../dev/syscons
SRCS+= scvesactl.c
.include <bsd.kmod.mk>vesa просто не вкомпилится в ядро, если не указать опцию X86EMU. Надо спрятать scvesactl.c за X86EMU тоже, иначе если указать VESA без X86EMU, то в ядре уже будет свой scvesactl.o и в vesa.ko тоже будет scvesactl.o.paradox писал(а):ну так тож у тебя
он у тебя оптионс в ядре стоит
ты имеешь в виду если X86EMU будет вкомпилено в ядро, а VESA модулем?paradox писал(а):так то уже дальше
а я щас о xemu86 говорил
о том что ты его ko модулем сделал
Код: Выделить всё
link_elf_obj: symbol x86emu_exec_intr undefined
linker_load_file: Unsupported file typeесли так делать, то будут дубликаты в dpms.ko. А с MODULE_DEPEND() мы просто добавляет x86emu в зависимость в dmps(4) и vesa(4) и получаем по одному x86emu.o и x86emu_util.o в ядре.paradox писал(а):я имел ввиду что emu86 должен лежать в контрибах
и юзаться токо в Makefile когда он нужен
проверил с X86EMU в ядре, но без VESAГость писал(а):ты имеешь в виду если X86EMU будет вкомпилено в ядро, а VESA модулем?
Код: Выделить всё
$ kldload x86emu
kldload: can't load x86emu: File exists
$ kldload vesa
$ kldstat
Id Refs Address Size Name
1 12 0xffffffff80100000 9f1240 kernel
2 1 0xffffffff80af2000 19cfa0 zfs.ko
3 2 0xffffffff80c8f000 5c08 opensolaris.ko
4 1 0xffffffff80e32000 30ba vesa.koя попробовал его драйвер. Но из-за того что повтор нажатий клавиш работает как-то криво, решил обратно сбежать на syscons(4). Я так понял он в sys/dev/vt/hw/vga/vga.c переключает карту в графический режим не используя bios вызовы. Чем такой подход хуже того что в vesa.c?paradox писал(а):потому как ed щас пилит сисконс и кое что меняет по не многу
возможно унего другие планы как и что поменять
потому что есть базовые vga регистры (по максимуму не разгонишься - 640x480 думаю максимум)Я так понял он в sys/dev/vt/hw/vga/vga.c переключает карту в графический режим не используя bios вызовы. Чем такой подход хуже того что в vesa.c?
кроме pmap_mapbios() у мя ядро паникует при загрузке, если я уберуparadox писал(а):токо появляеться такая фигняможешь попробовать по аналогии с vesa портировать
там всего лиш одна функция
токо я не совсем понял зачем он нужен
засыпание для монитора?
что нужно перетягивать xemu86 чуть ли не в ядро
или делать для него отдельные обертки
потому как на каждую вирутальную машину делать pmap_bios
Код: Выделить всё
vesa_emu.emu_inb = vm86_emu_inb;
vesa_emu.emu_inw = vm86_emu_inw;
vesa_emu.emu_inl = vm86_emu_inl;
vesa_emu.emu_outb = vm86_emu_outb;
vesa_emu.emu_outw = vm86_emu_outw;
vesa_emu.emu_outl = vm86_emu_outl;Код: Выделить всё
# acpiconf -s3
acpi0: suspend request ignored (not ready yet)
acpiconf: request sleep type (3) failed: Device not configuredможет быть лучше имя оставить прежнее vm86, а внутренности vm86 заменить на x86emu?paradox писал(а):это уже слишком
работать будет но не есть гуд
лучше сделать один раз
и сделать один констект глобальный типа vesa_emu токо под другим именем например xemu86_ctx
тогда будет видна одна глобальная функция аля x86emu_exec_intr(&xemu86_ctx, 0x10);
есть сомнение в том можно ли два раза мапить память итдкроме pmap_mapbios() у мя ядро паникует при загрузке, если я уберу
не имея доступа к репозиториюможет быть лучше имя оставить прежнее vm86, а внутренности vm86 заменить на x86emu?
я тут подумалможет быть лучше имя оставить прежнее vm86, а внутренности vm86 заменить на x86emu?
))